Публичный учет и аудит SSL сертификатов в Chrome

Браузеры доверяют сертификатам, если соблюдаются такие условия:

1. сертификат соответствует доменному имени
2. сертификат подписан доверенным центром сертификации
3. текущее время входит в проверенный период действия сертификата (notBefore - notAfter)
4. сертификат не отозван
5. промежуточные сертификаты CA не отозваны
6. корневой сертификат CA присутствует и не отозван

Однако остается "лазейка" для злоупотребления. Например Доверенный центр сертификации (CA) может выпустить сертификат используя подложные документы - такие прецеденты уже были ;), возможен так же выпуск запрещенных промежуточных сертификатов - такие прецеденты тоже были... Основная проблема состоит в том, что центры сертификации могут выпустить такие сертификаты конфиденциально. Вы не сможете узнать, что CA выпустил мошеннический сертификат, пока вы не столкнетесь с этим сертификатом и не изучите его. Следовательно, вы вполне можете стать целью злоумышленников. Чтобы предотвратить такие ошибки и подобные злоупотребления СА , история выпущенных сертификатов центрами сертификации (СА) должна быть публичной.

Цель CT состоит в том, чтобы запретить CA выдавать сертификаты открытых ключей для домена без ведома владельца домена. Прозрачность сертификата (КТ) обеспечивает жизнеспособный механизм для своевременного выявления выданных сертификатов. Это может быть очень важно для смягчения дальнейшего злоупотребления мошенническими сертификатами.

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

Список transparence журналов доступен на сайте Google. EV-сертификаты, выпущенные после 1 января 2015 года автоматически публикуются в контрольном журнале.

* DigiCert EV сертифиикаты имеют функцию отключения размещения в журнале функция "Do not make my certificate information public. Disables the green address bar in Google Chrome. Check the box if you do not want to publicly share your common name, SANs, and organization information."

Chrome выдает такие сообщения о SSL сертификате. Обратите внимание на public audit record : "Записи общедоступного аудита отсутствуют" для DV, OV и EV сертификатов с отключенной функцией transparence ( а так же сертификатов выпущенных до введения журналов)

	для DV сертификатов "Записи общедоступного аудита отсутствуют"
	для OV сертификатов "Записи общедоступного аудита отсутствуют"
	для EV сертификатов с отключенной transparence "Записи общедоступного аудита отсутствуют"
	для EV сертификатов приведено название компании и местонахождение

Транспаренция для ЕВ сертификатов

При включенной КТ для сертификата ваши клиенты могут видеть зеленую адресную строку в Google Chrome. При отключенном CT для сертификата зеленая адресная строка в Google Chrome не отображается. После выбора CT для сертификата информация этого сертификата является общедоступной. В целях конфиденциальности вы можете отключить КТ. Отключение CT означает, что информация вашего сертификата не указана в общедоступном протоколе CT.

С точки зрения конфиденциальности CT представляет собой сложную задачу. Если уполномоченный владелец веб-сайта по какой-либо причине не хочет публиковать свои данные сертификата публично, то сертификаты EV могут не работать должным образом с браузерами, которые применяют CТ. Просто подумайте о сертификате, выпущенном для внутреннего веб-сайта, для нового продукта в компанию, которая отчаянно охраняет информацию о своей новой продукции от утечки или секретный правительственный проект. CТ должна включать способ уважения и соблюдения такой конфиденциальности.

RFC 6962 - экспериментальный протокол для публичной регистрации наличия сертификатов безопасности транспортного уровня (TLS) по мере их выпуска или наблюдения таким образом, чтобы кто-либо мог проверять деятельность центра сертификации (CA) и уведомлять о выдаче подозрительных сертификатов, а также самостоятельно проверять журналы сертификатов. Цель состоит в том, что в конечном итоге клиенты отказываются соблюдать сертификаты, которые не отображаются в журнале, что фактически заставляет ЦС добавлять все выпущенные сертификаты в журналы. Журналы - это сетевые службы, которые реализуют операции протокола для представлений и запросов. Этот документ является продуктом Целевой группы Internet Engineering Task Force (IETF). Он представляет собой консенсус сообщества IETF. Он получил публичный обзор и был одобрен для публикации Руководящей группой Internet Engineering Steering Group (IESG). Не все документы, одобренные IESG, являются кандидатами на любой уровень интернет-стандарта; см. Раздел 2 RFC 5741

В дополнение к типичной конфигурации, описанной выше, где мониторы и аудиторы тесно интегрированы с существующими компонентами TLS / SSL, прозрачность сертификата поддерживает многие другие конфигурации. Например, мониторы могут работать как автономные объекты, предоставляя платные или неоплаченные услуги органам сертификации и операторам сервера . Монитор также может управляться оператором сервера, таким как большой объект Интернета, такой как Google, Microsoft или Yahoo. Аналогичным образом, одитор может работать как автономная служба или может быть вторичной функцией монитора.

Прозрачность сертификата направлена ​​на устранение проблемы ошибочных сертификатов, предоставляя публично проверенные, не зависящие от приложения, не проверенные журналы всех выданных сертификатов. Журналы публично проверяются, так что каждый может проверить правильность каждого журнала и контролировать, когда к нему добавляются новые сертификаты. Журналы сами по себе не предотвращают ошибочные действия, но они гарантируют, что заинтересованные стороны (особенно те, которые указаны в сертификатах) могут обнаружить такое нарушение. Обратите внимание, что это общий механизм, описывающий его использование для публичных сертификатов сервера TLS, выданных государственными органами сертификации (ЦС).

Каждый журнал состоит из цепочек сертификатов, которые могут быть представлены кем угодно. Ожидается, что государственные ЦС будут предоставлять все свои недавно выпущенные сертификаты одному или нескольким журналам; также ожидается, что владельцы сертификатов будут вносить свои собственные цепи сертификатов. Чтобы избежать бремени журналов в бесполезность, требуется, чтобы каждая цепочка была внедрена в известный сертификат ЦС. Когда цепочка отправляется в журнал, возвращается возвращенная метка времени, которая впоследствии может использоваться для предоставления доказательств клиентам, что цепочка была отправлена. Таким образом, клиенты TLS могут потребовать регистрации всех сертификатов, которые они видят.

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

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

Свойство append-only для каждого журнала технически достигается с использованием Merkle Trees, которое может использоваться, чтобы показать, что любая конкретная версия журнала является надмножеством любой конкретной предыдущей версии. Аналогично, деревья Меркле избегают необходимости слепого доверия журналам: если журнал пытается показать разные вещи другим людям, это можно эффективно обнаружить, сравнив корни деревьев и доказательства согласованности. Аналогичным образом, другие неправильные правила любого журнала (например, выдача подписанных временных меток для сертификатов, которые они затем не регистрируют) могут быть эффективно обнаружены и доказаны всему миру.

Как работает журнал CT

В CT участвуют 4 основных участника:

1. Центр сертификации
2. Журнальные лог серверы, которые действуют как публичный репозиторий SSL-сертификатов
3. Аудиторы (веб-браузеры или любой клиент, который принимает сертификат SSL)
4. Ваш компьютер

Во время установления связи TLS клиент TLS получает сертификат SSL и SCT сертификата. Как обычно, клиент TLS проверяет сертификат и свою цепочку подписи. Кроме того, клиент TLS проверяет подпись журнала на SCT, чтобы убедиться, что SCT был выпущен с помощью действительного журнала и что SCT был фактически выдан для сертификата (а не какого-либо другого сертификата) Если есть расхождения, клиент TLS может отклонить сертификат. Например, клиент TLS обычно отклоняет любой сертификат, чья временная метка SCT в будущем.

В центре системы сертификации прозрачности лежат журналы сертификатов. Журнал сертификатов - это простая сетевая служба, поддерживающая запись сертификатов SSL. Журналы сертификатов имеют три важных качества:

1. Они только для приложений - сертификаты могут быть добавлены только в журнал; сертификаты не могут быть удалены, изменены или ретроактивно вставлены в журнал.
2. Они криптографически гарантированы - журналы используют специальный криптографический механизм, известный как Merkle Tree Hashes, для предотвращения несанкционированного доступа и неправильного поведения.
3. Они публично проверяются - каждый может запросить журнал и убедиться, что он хорошо себя ведет, или проверить, что сертификат SSL был законно добавлен в журнал.

Перед выдачей SSL-сертификата CA отправляет всю информацию об этом сертификате на один или несколько серверов журналов, которым доверяют CA и аудиторы. Сервер журнала принимает сертификат и выдаёт сертификаты Cryptographically tamperproof уникальной проверки (Signed Timestamp Certificate - SCT) в CA. При выдаче SSL сертификата CA затем включает такие доказательства (сертификаты) внутри SSL сертификата клиента

CA также могут поставлять SCT с помощью сшивания Network Protocol Status Protocol (OCSP). В этом случае CA одновременно выдает сертификат серверу журнала и оператору сервера. Затем оператор сервера отправляет запрос OCSP в ЦС, а ЦС отвечает с помощью SCT, который сервер может включить в расширение OCSP во время установления связи TLS. Этот метод позволяет CAs взять на себя ответственность за SCT, но не задерживает выпуск сертификата, поскольку CA может получить SCT асинхронно. Однако он требует модификации сервера для сшивания OCSP.

Отличие существующей TLS/SSL системы от TLS/SSL использующий журнал транпаренции сертификатов CT

Когда браузер посещает веб-сайт с поддержкой SSL, он сначала проверяет сертификат SSL на различные записи. CT предлагает, чтобы браузеры, которые выполняют роль аудитора в CT, также должны проверять доказательства SCT, включенные в сертификат. CТ дает рекомендации о том, сколько доказательств должен иметь сертификат на основании срока действия сертификата. Браузер проверяет доказательства SCT на основе журнальных серверов, которым он доверяет. Чтобы доказательство SCT было действительным, браузер должен иметь открытый ключ сервера журнала выдачи в своем хранилище доверия CT. Здесь важно отметить, что браузер не всегда выполняет проверку в реальном времени с сервером журнала. Роль браузера в CT заключается главным образом в том, чтобы заставить ЦС публиковать сертификаты, которые они собираются выпустить, и включать доказательства (и) такой публикации.

Мониторы журнала CT могут быть разработаны и развернуты всеми, кто хочет продолжать просмотр вновь добавленных сертификатов на серверы журналов. Целью здесь является мониторинг журнальных серверов, которые могут обнаруживать ошибочные сертификаты для определенных веб-сайтов. Помимо внедрения доказательств SCT в сертификатах SSL они могут поставляться как расширение TLS или сшивание OCSP. Эти методы требуют предварительной настройки на веб-серверах.

CT - хорошая попытка сделать доступными все выданные SSL-сертификаты в одном или нескольких публичных хранилищах. Если СА решит не публиковать выданные сертификаты SSL для журнальных серверов, тогда браузеры могут решить, как обращаться с этим сертификатом. Таким образом, внутренняя ценность CT создается путем применения браузера (ов). В отсутствие обширного и диверсифицированного пула аудиторов КТ он не будет предоставлять полную ценность, которую он обещает. Настольные приложения, мобильные приложения и веб-службы, которые являются частью экосистемы SSL, должны участвовать в КТ, чтобы быть действительно эффективными.

Важно отметить, что CT не решает проблему неправильной выдачи, но облегчает обнаружение ошибочной выдачи. Существуют и другие решения, такие как CAA записи, которые направлены на предотвращение ошибочного выпуска, но по-другому. В CAA владелец веб-сайта указывает в записях DNS, какие CA могут выдавать сертификаты на свой веб-сайт. Каждый CA, который поддерживает CAA, должен проверять такое разрешение до выдачи сертификата. Можно утверждать, что это необязательно, но если приведение в действие аудитора / браузера аналогично тому, что присутствует в КТ, тогда ВГА может быть эффективным в предотвращении ошибочной выдачи.

Часто задаваемые вопросы о прозрачности сертификатов FAQ

Что такое прозрачность сертификата?
Прозрачность сертификата (CT) - это инициатива Google для регистрации, аудита и мониторинга сертификатов, выпущенных ЦС. Цель CT заключается в том, чтобы не допускать выдачу сертификатов открытого ключа (CA) сертификатов открытого ключа для домена без ведома владельца домена. Google обязуется, чтобы все центры сертификации (CA) должны регистрировать все сертификаты Extended Validation в публично проверяемых журналах с добавлением только для зеленой адресной строки, которые появятся в Chrome. Этот план начинается в феврале 2015 года. CT не заменяет традиционные процедуры проверки подлинности и проверки, которые применяют DigiCert и другие CA. Это дополнительный способ проверить, что ваш сертификат уникален.

Включение и открючение записей в CT для сертификатов SSL DigiCert, GeoTrust и Thawte

DigiCert, GeoTrust and Thawte позволяют отключить запись лога в журнал по желанию заказчика сертификата SSL, по умолчанию запись будет включена в поле certificate extension OID 1.3.6.1.4.1.11129.2.4.2

Что произойдет, если я не включу CT?
Если вы не используете прозрачность сертификата, зеленая адресная строка для сертификатов EV в Google Chrome исчезает

Я могу сначала отключить запись в журнал CT а потом включить?
Да, для этого вам необходимо сделать перевыпуск сертификата и указать при заказе что вы хотите

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

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

Как эта информация используется?
Владельцы сертификатов могут использовать журналы, чтобы определить, что их сертификат уникален, но для получения доступа к журналам необходимы соответствующие аппаратные и программные ресурсы. Другие люди и компании, имеющие доступ к журналам, могут использовать информацию по своему усмотрению. Обратите внимание, что это информация, которая уже отображается в подробностях вашего сертификата. Если ваш сертификат является общедоступным, каждый может увидеть эту информацию сегодня.