Прозрачность сертификата
Система публичных журналов цифровых сертификатов

Certificate Transparency ( CT ) — это стандарт безопасности Интернета для мониторинга и аудита выдачи цифровых сертификатов . [1] Когда пользователь Интернета взаимодействует с веб-сайтом, необходима доверенная третья сторона для подтверждения того, что веб-сайт является законным и что ключ шифрования веб-сайта действителен. Эта третья сторона, называемая центром сертификации (CA), выдаст сертификат для веб-сайта, который браузер пользователя может проверить. Безопасность зашифрованного интернет-трафика зависит от доверия к тому, что сертификаты выдаются только центром сертификации и что центр сертификации не был скомпрометирован.

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

Работа над прозрачностью сертификатов началась в 2011 году после того, как центр сертификации DigiNotar был скомпрометирован и начал выдавать вредоносные сертификаты. Инженеры Google представили проект в Internet Engineering Task Force (IETF) в 2012 году. Результатом этих усилий стал IETF RFC  9162, стандарт, определяющий систему публичных журналов для записи всех сертификатов, выданных публично доверенными центрами сертификации , что позволяет эффективно идентифицировать ошибочно или злонамеренно выданные сертификаты. [2]

Технический обзор

Система прозрачности сертификатов состоит из системы журналов сертификатов только для добавления . Журналы управляются многими сторонами, включая поставщиков браузеров и центры сертификации . [3] Сертификаты, которые поддерживают прозрачность сертификатов, должны включать одну или несколько подписанных временных меток сертификатов (SCT), что является обещанием оператора журнала включить сертификат в свой журнал в течение максимальной задержки слияния (MMD). [4] [3] В какой-то момент в течение максимальной задержки слияния оператор журнала добавляет сертификат в свой журнал. Каждая запись в журнале ссылается на хэш предыдущей, образуя дерево Меркла . Подписанная голова дерева (STH) ссылается на текущий корень дерева Меркла .

Процедура регистрации

Хотя любой желающий может отправить сертификат в журнал CT, эта задача обычно выполняется центром сертификации следующим образом: [4] [5]

  1. Заявитель, «физическое или юридическое лицо, которое подает заявку на получение (или стремится к продлению) сертификата» [6] , запрашивает сертификат у центра сертификации.
  2. Центр сертификации выдает специальный предварительный сертификат, который содержит расширение «Positive», сигнализирующее о том, что он не должен приниматься пользовательскими агентами.
  3. Центр сертификации отправляет предварительный сертификат в журналы.
  4. Журналы возвращают соответствующие SCT в CA.
  5. Центр сертификации прикрепляет SCT, собранные из журналов, в качестве расширения X.509 к окончательному сертификату и предоставляет его заявителю.

Наконец, CA может решить также регистрировать окончательный сертификат. Например, Let's Encrypt E1 CA регистрирует как предварительные сертификаты, так и окончательные сертификаты (см. страницу профиля CA crt.sh в разделе «выданные сертификаты»), тогда как Google GTS CA 2A1 этого не делает (см. страницу профиля crt.sh).

Обязательная прозрачность сертификата

Некоторые браузеры требуют, чтобы сертификаты Transport Layer Security (TLS) имели подтверждение регистрации с прозрачностью сертификата [7] [8] либо через SCT, встроенные в сертификат, расширение во время рукопожатия TLS, либо через OCSP :

БраузерТекущие требования SCTТекущие требования к расширению OCSP/TLS
Хром / Хром
  • Один SCT из текущего утвержденного журнала
  • Продолжительность ≤ 180 дней: 2 SCT из однажды утвержденных журналов
  • Продолжительность > 180 дней: 3 SCT из однажды утвержденных журналов [9] [10]
  • 1 SCT из текущего журнала Google
  • 1 SCT из текущего журнала, не относящегося к Google
FirefoxНет [11]Никто
Сафари
  • Один SCT из текущего утвержденного журнала
  • Продолжительность ≤ 180 дней: 2 SCT из однажды утвержденных журналов
  • Продолжительность > 180 дней: 3 SCT из однажды утвержденных журналов [12]
Два SCT из текущих утвержденных журналов

Разделение журнала

Из-за большого количества сертификатов, выпущенных с помощью Web PKI , журналы прозрачности сертификатов могут разрастаться и содержать много сертификатов. Такое большое количество сертификатов может вызвать нагрузку на журналы. Временное сегментирование — это метод снижения нагрузки на журналы путем сегментирования журнала на несколько журналов и принятия каждым шардом только предварительных сертификатов и сертификатов с датой истечения срока действия в определенный период времени (обычно календарный год). [13] [14] [15] Серия журналов Nimbus от Cloudflare была первой, в которой использовалось временное сегментирование.

Фон

Преимущества

Одной из проблем управления цифровыми сертификатами является то, что мошеннические сертификаты долго обнаруживаются, сообщаются и отзываются . Выданный сертификат, не зарегистрированный с помощью Certificate Transparency, может вообще никогда не быть обнаружен. Главное преимущество Certificate Transparency заключается в возможности для групп кибербезопасности защищать компании и организации путем мониторинга подозрительных доменов, регистрирующих сертификаты. Новые сертификаты для этих подозрительных доменов могут иметь похожие имена с другими законными доменами и предназначены для использования для поддержки вредоносных действий, таких как фишинговые атаки. Certificate Transparency дает группам кибербезопасности контроль и позволяет им выдавать приказы об удалении подозрительных доменов и применять средства контроля кибербезопасности на веб-прокси и почтовых шлюзах для немедленной защиты. [16]

Побочные эффекты

Доменные имена, которые используются во внутренних сетях и имеют сертификаты, выданные центрами сертификации, становятся общедоступными для поиска, поскольку их сертификаты добавляются в журналы CT.

Журналы прозрачности сертификатов

Прозрачность сертификата зависит от проверяемых журналов прозрачности сертификата. Журнал добавляет новые сертификаты к постоянно растущему дереву хэшей Меркла . [1] : §4  Чтобы журнал считался работающим правильно, он должен:

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

Журнал может принимать сертификаты, которые еще не полностью действительны, а также сертификаты, срок действия которых истек.

Сертификат Прозрачность мониторов

Мониторы действуют как клиенты для серверов журналов. Мониторы проверяют журналы, чтобы убедиться, что они ведут себя правильно. Несоответствие используется для доказательства того, что журнал вел себя неправильно, а подписи в структуре данных журнала (дерево Меркла) не позволяют журналу отрицать это неправильное поведение.

Сертификаты прозрачности аудиторов

Аудиторы также действуют как клиенты для серверов журналов. Аудиторы прозрачности сертификатов используют частичную информацию о журнале для проверки журнала относительно другой частичной информации, которой они располагают. [1] : §8.3 

Программы регистрации прозрачности сертификатов

У Apple [17] и Google [13] есть отдельные программы журналов с различными политиками и списками доверенных журналов.

Корневые хранилища журналов прозрачности сертификатов

Журналы прозрачности сертификатов поддерживают собственные корневые хранилища и принимают только сертификаты, которые связаны с доверенными корнями. [1] В прошлом ряд некорректно работающих журналов публиковали несогласованные корневые хранилища. [18]

История

Пример записи прозрачности сертификата в Firefox 89

В 2011 году был атакован реселлер центра сертификации Comodo , а центр сертификации DigiNotar был скомпрометирован , [19] продемонстрировав существующие недостатки в экосистеме центра сертификации и побудив к работе над различными механизмами для предотвращения или мониторинга несанкционированной выдачи сертификатов. Сотрудники Google Бен Лори , Адам Лэнгли и Эмилия Каспер начали работу над фреймворком с открытым исходным кодом для обнаружения неправильно выпущенных сертификатов в том же году. В 2012 году они представили первый проект стандарта в IETF под кодовым названием «Sunlight». [20]

В марте 2013 года Google запустил свой первый журнал прозрачности сертификатов. [21]

В июне 2013 года был опубликован документ RFC  6962 «Прозрачность сертификатов», основанный на проекте 2012 года.

В сентябре 2013 года DigiCert стал первым центром сертификации , внедрившим прозрачность сертификатов. [22]

В 2015 году Google Chrome начал требовать прозрачность сертификатов для вновь выпущенных сертификатов расширенной проверки . [23] [24] Он начал требовать прозрачность сертификатов для всех сертификатов, вновь выпущенных Symantec с 1 июня 2016 года, после того как было обнаружено, что они выпустили 187 сертификатов без ведома владельцев доменов. [25] [26] С апреля 2018 года это требование было распространено на все сертификаты. [8]

23 марта 2018 года Cloudflare анонсировала собственный журнал CT под названием Nimbus . [27]

В мае 2019 года центр сертификации Let's Encrypt запустил собственный журнал CT под названием Oak. С февраля 2020 года он включен в утвержденные списки журналов и может использоваться всеми публично доверенными центрами сертификации. [28]

В декабре 2021 года  был опубликован RFC 9162 «Certificate Transparency Version 2.0». [1] Версия 2.0 включает в себя основные изменения в требуемой структуре сертификата журнала, а также поддержку Ed25519 в качестве алгоритма подписи SCT и поддержку включения доказательств включения сертификата в SCT.

В феврале 2022 года Google опубликовала обновление своей политики CT, [29] которое отменяет требование к сертификатам включать SCT из собственной службы журналов CT, приведя все требования к сертификатам в соответствие с ранее опубликованными Apple. [30]

Алгоритмы подписи

В версии Certificate Transparency 2.0 журнал должен использовать один из алгоритмов в реестре IANA «Алгоритмы подписи». [1] : 10.2.2  [31]

Инструменты для проверки журналов КТ

  • Карта Меркле
  • crt.sh от Sectigo
  • Поиск Censys
  • Cert Spotter от sslmate
  • certstream.calidog.io
  • ct.cloudflare.com - Город Меркл от Cloudflare
  • Мета-контроль прозрачности сертификатов от Meta
  • Сертификат прозрачности Root Explorer
  • EZMonitor от Keytos [32]

Смотрите также

Ссылки

  1. ^ abcdef Certificate Transparency Version 2.0. Декабрь 2021 г. doi : 10.17487/RFC9162 . RFC 9162.
  2. ^ Соломон, Бен (8 августа 2019 г.). "Введение в мониторинг прозрачности сертификатов". Cloudflare . Архивировано из оригинала 8 августа 2019 г. Получено 9 августа 2019 г. Ах , прозрачность сертификатов (CT). CT решает проблему, которую я только что описал, делая все сертификаты общедоступными и простыми для аудита. Когда центры сертификации выдают сертификаты, они должны отправлять сертификаты как минимум в два "публичных журнала". Это означает, что в совокупности журналы содержат важные данные обо всех доверенных сертификатах в Интернете.
  3. ^ ab Scheitle, Quirin; Gasser, Oliver; Nolte, Theodor; Amann, Johanna; Brent, Lexi; Carle, Georg; Holz, Ralph; Schmidt, Thomas C.; Wählisch, Matthias (2018-10-31). «Рост прозрачности сертификатов и ее влияние на экосистему Интернета». Труды конференции по измерению Интернета 2018 г. Бостон, Массачусетс, США: ACM. стр.  343–349 . doi : 10.1145/3278532.3278562 . ISBN 978-1-4503-5619-0. S2CID  52814744.
  4. ^ ab "Как работает CT: прозрачность сертификата". certificate.transparency.dev . Архивировано из оригинала 2022-02-25 . Получено 2022-02-25 .
  5. ^ "Certificate Transparency (CT) Logs". Let's Encrypt. Архивировано из оригинала 2024-01-04 . Получено 2024-01-04 .
  6. ^ "Базовые требования к выпуску и управлению публично-доверенными сертификатами" (PDF) . Форум CA/B. Архивировано (PDF) из оригинала 4 января 2024 г. . Получено 4 января 2024 г. .
  7. ^ Call, Ashley (2015-06-03). "Прозрачность сертификатов: часто задаваемые вопросы | Блог DigiCert". DigiCert . Архивировано из оригинала 20-05-2022 . Получено 13-04-2021 .
  8. ^ ab O'Brien, Devon (7 февраля 2018 г.). «Обеспечение прозрачности сертификатов в Google Chrome». Группы Google. Архивировано из оригинала 23 мая 2013 г. Получено 18 декабря 2019 г.
  9. ^ Это применимо к сертификатам, выданным 15 апреля 2022 года или позже. Для более старых сертификатов применяются другие критерии.
  10. ^ "Политика прозрачности сертификатов Chrome". CertificateTransparency . Архивировано из оригинала 2022-02-20 . Получено 26-02-2022 .
  11. ^ "Прозрачность сертификатов - веб-безопасность | MDN". developer.mozilla.org . Архивировано из оригинала 2022-02-22 . Получено 2022-02-26 .
  12. ^ "Политика прозрачности сертификатов Apple". Служба поддержки Apple . 5 марта 2021 г. Архивировано из оригинала 2022-02-26 . Получено 2022-02-26 .
  13. ^ ab "Chrome CT Log Policy". googlechrome.github.io . Архивировано из оригинала 2021-10-26 . Получено 2021-10-14 .
  14. ^ Томеску, Алин; Бхупатираджу, Вивек; Пападопулос, Димитриос; Папамантхоу, Харалампос; Триандопулос, Никос; Девадас, Шринивас (2019-11-06). «Журналы прозрачности через аутентифицированные словари только для добавления». Труды конференции ACM SIGSAC 2019 года по компьютерной и коммуникационной безопасности . Лондон, Соединенное Королевство: ACM. стр.  1299–1316 . doi : 10.1145/3319535.3345652 . ISBN 978-1-4503-6747-9. S2CID  52034337.
  15. ^ "Масштабирование журналов CT: временное разделение | DigiCert.com". www.digicert.com . Архивировано из оригинала 2022-02-26 . Получено 2022-02-26 .
  16. ^ "Архивная копия". Архивировано из оригинала 2025-01-10 . Получено 2025-01-10 .{{cite web}}: CS1 maint: архивная копия как заголовок ( ссылка )
  17. ^ "Программа журнала прозрачности сертификатов Apple". apple.com . 28 января 2019 г. Архивировано из оригинала 27.10.2021 . Получено 14.10.2021 .
  18. ^ Коржицкий, Никита; Карлссон, Никлас (2020). Характеристика корневого ландшафта журналов Certificate Transparency . arXiv : 2001.04319 . {{cite book}}: |work=проигнорировано ( помощь )
  19. ^ Bright, Peter (30 августа 2011 г.). «Еще один мошеннический сертификат поднимает те же старые вопросы о центрах сертификации». Ars Technica . Архивировано из оригинала 2018-02-10 . Получено 2018-02-10 .
  20. ^ Лори, Бен; Лэнгли, Адам; Каспер, Эмилия (12.09.2012). "Прозрачность сертификата (draft-laurie-pki-sunlight)". ietf.org . IETF . Архивировано из оригинала 29.05.2023 . Получено 28.05.2023 .
  21. ^ "Известные журналы - Прозрачность сертификата". certificate-transparency.org . Архивировано из оригинала 2016-12-16 . Получено 2015-12-31 .
  22. ^ "DigiCert объявляет о поддержке прозрачности сертификатов". Dark Reading. 2013-09-24. Архивировано из оригинала 2018-11-01 . Получено 2018-10-31 .
  23. ^ Woodfield, Meggie (5 декабря 2014 г.). «Требуется прозрачность сертификата для отображения зеленой адресной строки в Chrome для сертификатов EV». Блог DigiCert . DigiCert . Архивировано из оригинала 13 октября 2016 г. . Получено 31 декабря 2015 г. .
  24. ^ Лори, Бен (4 февраля 2014 г.). "Обновленная прозрачность сертификатов + расширенный план проверки". public@cabforum.org (список рассылки). Архивировано из оригинала 2014-03-30.
  25. ^ "Symantec Certificate Transparency (CT) для сертификатов, выпущенных до 1 июня 2016 г.". Symantec Knowledge Center . Symantec . 9 июня 2016 г. Архивировано из оригинала 5 октября 2016 г. Получено 22 сентября 2016 г.
  26. ^ Sleevi, Ryan (28 октября 2015 г.). «Поддержание безопасности цифровых сертификатов». Блог безопасности Google . Архивировано из оригинала 7 декабря 2016 г. Получено 22 сентября 2016 г.
  27. ^ Салливан, Ник (23 марта 2018 г.). «Введение в прозрачность сертификатов и Nimbus». cloudflare.com . Архивировано из оригинала 23 марта 2018 г. . Получено 9 августа 2019 г. .
  28. ^ "Представляем Oak, бесплатный и открытый журнал прозрачности сертификатов - Let's Encrypt". letsencrypt.org . Архивировано из оригинала 2021-04-13 . Получено 2021-04-13 .
  29. ^ "Обновление политики Google CT". Группы Google . Архивировано из оригинала 2022-02-10 . Получено 2022-02-14 .
  30. ^ "Политика прозрачности сертификатов Apple". support.apple.com . 5 марта 2021 г. Архивировано из оригинала 2022-02-14 . Получено 2022-02-14 .
  31. ^ "Алгоритмы подписи". Public Notary Transparency . IANA . Получено 28.05.2023 .
  32. ^ "Мониторы: Прозрачность сертификата". certificate.transparency.dev . Архивировано из оригинала 2023-02-27 . Получено 2023-03-06 .
  • Официальный сайт
  • RFC  9162 Certificate Transparency Version 2.0 (который заменил предыдущий RFC  6962)
  • crt.sh, поисковая система журнала прозрачности сертификатов
  • Отчет о прозрачности сертификата Google
  • Мониторинг прозрачности сертификатов с помощью Meta
  • Тест КТ на badssl.com
Получено с "https://en.wikipedia.org/w/index.php?title=Прозрачность_сертификата&oldid=1271788515"