Comments 8
Сама концепция цепочек доверия порочна по своей сути, никакие костыли ей не помогут.
В идеале же сам новый сертификат должен быть подписан старым и доступен через специальный API
А разве сейчас не так?
Проблема курицы и яйца видимо никогда не потеряет актуальность.
Правильно ли я понял, что вы предлагаете расширить текущий стандарт добавлением поля с адресом онлайн - сервиса удостоверяющего центра с новыми корневыми сертификатами, и механизм их автоматической установки? Оставив в стороне вопрос об инерционности отрасли (и вообще, зачем что-то менять), как будут при вашей схеме решаться следующие вопросы:
Проверка того, что новый выложенный сертификат является валидным, т.е. действительно выпущен тем же удостоверяющим центром (а не хакерами, дефейснувшими сайт, например, или отправившись жертву на поддельный сервис)? Если не путаю, корневой сертификат как раз и называется корневым потому, что он самоподписан самим удостоверяющим центром, дополнительных подписей от другого или этого же УЦ там быть не должно. Максимум, что мы можем - выпустить новый сертификат со старым закрытым ключом.
Работа в режиме оффлайн, когда доступа в интернет в принципе нет. В текущей схеме, если не проверять списки отзыва, доверие выстраивается математически. Если будет механизм автобновления корневых сертификатов, их, вероятно, будут менять чаще - ровно как сейчас разработчики браузеров не рекомендуют выписывать сертификаты на сайты сроком больше года.
Сейчас механизм истечения срока действия сертификата гарантирует, что даже если УЦ будет скомпрометирован, перестанет существовать, сменит собственника и т.п., его сертификату рано или поздно перестанут доверять все системы, даже не имеющие доступа к обновлению из независимых от УЦ источников. Что делать с этим?
В догонку, из того, что мы сейчас доверяем УЦ, не следует, что мы планируем ему доверять неограниченное время. Доверие к УЦ вообще сложный вопрос, и решается, буквально, доверием основных разработчиков ОС и браузеров.
Как будет работать механизм обновления, если устройство было в оффлайне / выключено / недоступно и оказывается доступным в момент, когда срок действия корневого сертификата УЦ уже прошёл?
Максимум, что мы можем - выпустить новый сертификат со старым закрытым ключом.
В виде костыля можно использовать кросс-подписание, когда корневой серт подписывается не только выпустившим его УЦ, но и еще несколькими авторитетными. Но тут, полагаю, все упрется в амбиции УЦ.
Если не путаю, корневой сертификат как раз и называется корневым потому, что он самоподписан самим удостоверяющим центром, дополнительных подписей от другого или этого же УЦ там быть не должно.
Справедливости ради, кросс-подписанный корневой сертификат одно время был у Let's Encrypt, пока они его распространяли по устройствам. Косяков там, конечно, тоже порядочно выплыло, но факт остаётся фактом.
UPD: Я буду обновлять комментарии перед отправкой... Когда-нибудь...
Есть DANE.
Вот только решим проблему последней мили в dnssec и пошлём нафиг эти централизованные CA. Станем сами себе CA.
Фундаментальная проблема TLS/SSL или как потерять доверие к доверенным центрам