Certificate Transparency

Certificate Transparency (CT) — это открытая система аудита и мониторинга сертификатов X.509, предназначенная для обнаружения ошибочно выданных или скомпрометированных цифровых сертификатов, используемых в инфраструктуре открытых ключей (PKI) веб-сайтов. Система была разработана для повышения безопасности протокола HTTPS и предотвращения атак, связанных с подделкой сертификатов удостоверяющими центрами (УЦ) или злоумышленниками.

История

Идея Certificate Transparency возникла как ответ на серию инцидентов, связанных с компрометацией удостоверяющих центров. В 2011 году хакеры получили доступ к серверу УЦ Comodo и выдали несколько поддельных сертификатов для популярных доменов, включая Google, Yahoo и Skype. В 2012 году был взломан УЦ DigiNotar, что привело к выдаче сотен поддельных сертификатов, в том числе для доменов правительства Ирана. Эти события показали, что традиционная модель PKI, основанная на доверии к УЦ, уязвима: любой УЦ может выдать сертификат для любого домена без ведома его владельца.

В 2013 году инженеры Google Бен Лори, Адам Лэнгли и Эмили Старк предложили концепцию Certificate Transparency в документе «Certificate Transparency: Public, Verifiable, Append-Only Log». Система была внедрена в браузере Google Chrome начиная с версии 53 (2016 год), а с 2018 года стала обязательной для всех сертификатов, выпущенных после 30 апреля 2018 года, чтобы они считались доверенными в Chrome.

Принцип работы

Certificate Transparency основана на трёх ключевых компонентах: журналы (logs), мониторы (monitors) и аудиторы (auditors).

Журналы (Logs)

Журнал — это общедоступный, криптографически защищённый реестр, в который УЦ обязаны отправлять каждый выпущенный сертификат перед его использованием. Журнал представляет собой неизменяемую структуру данных, реализованную в виде дерева Меркла. Каждая запись (сертификат) добавляется в конец журнала, и целостность всего журнала может быть проверена с помощью корневого хеша дерева.

УЦ получает от журнала подписанное подтверждение (Signed Certificate Timestamp, SCT), которое доказывает, что сертификат был зарегистрирован в журнале. SCT затем включается в сам сертификат или передаётся браузеру через расширение TLS или протокол OCSP.

Мониторы (Monitors)

Мониторы — это сервисы, которые постоянно следят за содержимым журналов. Они могут проверять, не появился ли в журнале сертификат для определённого домена, который не был запрошен его владельцем. Мониторы помогают владельцам доменов обнаруживать поддельные сертификаты в реальном времени.

Аудиторы (Auditors)

Аудиторы — это программные компоненты (часто встроенные в браузеры), которые проверяют, что журнал ведёт себя честно и не удаляет старые записи. Аудитор может запросить у журнала доказательство того, что определённый сертификат присутствует в журнале, и проверить это доказательство с помощью криптографии.

Виды SCT

Существует три основных способа доставки SCT в браузер:

1. Встроенный в сертификат (Embedded SCT): УЦ включает SCT непосредственно в сертификат при его выпуске. Этот метод наиболее распространён и не требует дополнительной настройки на стороне сервера.
2. Расширение TLS (TLS extension): SCT передаётся сервером во время рукопожатия TLS как отдельное расширение. Этот метод требует поддержки со стороны серверного программного обеспечения.
3. OCSP Stapling: SCT передаётся вместе с ответом OCSP (Online Certificate Status Protocol). Этот метод также требует настройки сервера, но позволяет уменьшить задержки.

Требования к сертификатам

С 30 апреля 2018 года Google Chrome требует, чтобы все сертификаты, выпущенные после этой даты, содержали хотя бы один SCT от журнала, включённого в список доверенных браузера. Если сертификат не соответствует этому требованию, Chrome отображает предупреждение об ошибке безопасности. Другие браузеры, такие как Safari и Firefox, также внедрили поддержку Certificate Transparency, хотя их требования могут различаться.

Критика и ограничения

Несмотря на свою эффективность, Certificate Transparency имеет ряд недостатков:

• Сложность внедрения: Для небольших УЦ и владельцев сайтов настройка SCT может быть технически сложной.
• Зависимость от журналов: Если журнал будет скомпрометирован или станет недоступен, система может дать сбой.
• Конфиденциальность: Журналы содержат все сертификаты, включая те, которые владельцы доменов могли бы предпочесть не раскрывать (например, для внутренних сервисов).
• Задержки: Процесс регистрации сертификата в журнале может увеличить время выпуска сертификата.

Применение в России

В России использование Certificate Transparency регулируется общими требованиями к безопасности интернет-соединений. Удостоверяющие центры, аккредитованные Министерством цифрового развития, связи и массовых коммуникаций РФ, обязаны соблюдать стандарты PKI, однако обязательное внедрение CT для всех сертификатов, выпускаемых в России, не установлено. Владельцы сайтов, использующих сертификаты от международных УЦ, таких как Let’s Encrypt или DigiCert, автоматически получают SCT в рамках стандартной процедуры выпуска.

Будущее развития

Certificate Transparency продолжает развиваться. В 2021 году была предложена версия 2 протокола (Certificate Transparency v2), которая включает улучшенные механизмы проверки и снижение нагрузки на журналы. Также ведутся работы по интеграции CT с другими системами безопасности, такими как DNS-based Authentication of Named Entities (DANE) и HTTP Public Key Pinning (HPKP), хотя последний был признан устаревшим.