Как Certificate Transparency защищает пользователей и владельцев домена

Вся современная инфраструктура открытых ключей (PKI) стоится на доверии, это очень важный вопрос, потому что, выстраивая отношения доверия с удостоверяющим центром (CA) вы создаете область доверия, соглашаясь безусловно доверять всем его действиям.

На практике это заключается в установке корневого сертификата УЦ, после чего все подписанные им сертификаты также будут считаться доверенными. На практике все конечно немного сложнее, но общий принцип не меняется. Доверяя УЦ, мы доверяем всем выпущенным им сертификатам.

А что, если мы УЦ доверяем, но как бы не до конца, тем более что список корневых сертификатов основных удостоверяющих центров поставляется нам в составе системы. Тем более, что прецеденты уже были, когда удостоверяющие центры по ошибке или злонамеренно выпускали сертификаты без ведома владельца домена.

Такой сертификат позволяет, используя отношения доверия к выпустившему его УЦ совершить атаку человек посередине (MitM), т.е. перехватить, прочитать и/или изменить трафик к легальному ресурсу без ведома пользователя.

Чтобы избежать такого сценария и повысить уровень доверия, а также сделать более прозрачным процесс выдачи сертификатов была придумана и внедрена технология Certificate Transparency.

Certificate Transparency предполагает создание публичных CT-логов, в которых удостоверяющие центры регистрируют все выданные сертификаты. CT-логи построены на основе двоичных деревьев Меркла и допускают только добавление информации, изменить или удалить внесенную запись не получится.

Второй ключевой момент – СT-логи доступны для внешнего аудита и уже сегодня существуют независимые службы, которые занимаются их мониторингом. Это позволяет защитить владельца домена, которого такая служба будет своевременно уведомлять о действиях с его сертификатами.

Допустим, какой-то УЦ «по ошибке» выпустил сертификат без ведома владельца – настоящий владелец получит уведомление об этом и сможет своевременно начать разбирательство, а также уведомить контрагентов, что доверять такому-то сертификату не следует.

Но нас больше интересует каким образом Certificate Transparency защищает пользователей? При регистрации сертификата в CT-логе удостоверяющий центр получает специальную SCT-метку, которую включает в сертификат.

Современные браузеры проверяют не только отношения доверия к выпустившему сертификат УЦ, но и к наличию как минимум двух SCT-меток от разных CT-логов. Ряд браузеров имеет более строгие условия, так Google Chrome или Safari требуют, чтобы одним из CT-логов был лог Google или Apple.

Таким образом информация о любом сертификате добросовестного УЦ будет распространена по большому количеству CT-логов и будет доступна для внешнего аудита, что делает махинации с сертификатами быстро выявляемыми.

Кстати, УЦ Минцифры также поддерживает СТ-логи и выпускает сертификаты только с их поддержкой. С Минцифрой работают службы CT-логов самой Минцифры, Яндекса и ВК.

Может ли УЦ выпустить сертификат, не регистрируя его в CT-логах? Может, но браузеры тут-же пометят такой сертификат не доверенным. Для этого браузеру даже не нужно связываться со службами CT-логов, достаточно отсутствия SCT-меток.

Технически получить STC-метку не регистрируя сертификат в логе можно, для этого нужно знать алгоритм формирования метки и иметь доступ к закрытому ключу лога. И тот же УЦ может провернуть такой фокус со своим CT-логом. Но как быть с остальными?

Сговор? Тоже не поможет, CT-логи публичны и отсутствие там записи для метки будет достаточно быстро обнаружено, что сразу сделает лог недоверенным.

Таким образом Certificate Transparency предоставляет может и не идеальный, но достаточно эффективный инструмент контроля над добросовестностью участников отношений доверия и исходит из принципа – доверяй, но проверяй.

Теперь, даже имея доверительные отношения с УЦ вы можете проверить, что УЦ ведет деятельность прозрачно и регистрирует сертификаты в независимых CT-логах, а при желании можете спокойно ознакомиться с их содержимым.