Политика доверия Certificate Transparency log

Проверяя сертификаты сайтов, браузеры следуют принципу: доверие к удостоверяющему центру влечет за собой доверие к сертификатам, которые тот выпускает. Иногда удостоверяющие центры выпускали сертификаты для домена без разрешения его владельца, например, в целях тестирования. Если злоумышленнику попадет в руки такой сертификат вместе с закрытым ключом, он сможет организовать Атаку посредника (Man-in-the-middle), потому что с точки зрения браузера сертификат действителен.

Для решения этой проблемы с сертификатами был создан стандарт Certificate Transparency. Информация о каждом выпущенном сертификате записывается в специальные логи Certificate Transparency. Мониторинг таких логов позволяет отследить выпуски всех сертификатов для домена и не пропустить ошибочный.

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

CT-логи находятся в открытом доступе, что позволяет:

• пользователям и браузерам — отслеживать выпуск всех сертификатов для домена и проверять их подлинность;
• владельцам сайтов — обнаруживать несанкционированную выдачу сертификатов.

При регистрации сертификата в CT-логе удостоверяющему центру выдается подписанная метка времени (Signed Certificate Timestamp, далее SCT) этого сертификата. Удостоверяющий центр передает владельцу сайта сертификат вместе с меткой. Когда браузер устанавливает соединение с сайтом, сервер вместе с сертификатом должен предоставить метку времени одного, а лучше нескольких логов.

В настоящее время Браузер доверяет сертификатам, содержащим одну метку времени из CT-лога Яндекса (описан в начале списка доверенных CT-логов НУЦ). В скором времени Браузер начнет доверять сертификатам, содержащим одну метку времени из любого CT-лога в списке доверенных и одну метку времени из CT-лога Яндекса.

В отношении CT-логов, выпущенных другими удостоверяющими центрами, Браузер придерживается политики Google.

Владелец CT-лога обязан:

• Удовлетворять всем требованиям стандарта RFC 6962, включая реализацию адресов для API, определенных в разделе 4.
• Поддерживать доступность лога на уровне 99% или выше, не отключая лог на время, превышающее максимальную задержку слияния (Maximum Merge Delay, далее MMD), указанную при регистрации. Доступность лога определяется по данным Яндекса, а не владельца лога.
• Не допускать сбоев, превышающих MMD более чем на 24 часа. Требование касается сбоев на сетевом уровне, окончания срока действия SSL-сертификата лога, отказа в регистрации сертификата, отличных от 200 кодов состояния HTTP-ответа, а также ответов, не соответствующих требованиям RFC 6962.
• Не ограничивать извлечение или совместное использование данных лога.
• Поддерживать лог доступным только для добавления информации.
• Передавать согласованное представление дерева Меркла по любому запросу в любое время.
• Представления дерева Меркла, которые владелец передает в разное время или разным сторонам, не должны отличаться друг от друга.
• Включать в лог сертификаты, для которых выдана метка времени, в пределах MMD.
• Получив просьбу зарегистрировать сертификат, уже включенный в лог, либо вернуть владельцу сайта ранее выданный SCT, либо добавить новую запись сертификата в пределах MMD, чтобы новый SCT можно было проверить с помощью API, описанного в RFC 6962.
• Уведомлять команду Яндекса обо всех изменениях в данных заявки на включение лога в список доверенных по электронной почте.

Нарушение требований может привести к удалению CT-лога из списка доверенных. Браузер не будет доверять меткам такого лога. Содержащиеся в логе сертификаты останутся доверенными, только если они будут содержать метки других логов.

1. Направьте заявку команде Яндекса по электронной почте. В заявке укажите:

   • адрес электронной почты, который регулярно просматриваете;
   • ФИО представителей, которые будут взаимодействовать с командой Яндекс Браузера.

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

   • Общедоступный адрес вашего CT-лога, который будет отвечать на все запросы клиентов, указанные в RFC 6962, раздел 4.
   • Открытые ключи лога в виде двоичного файла в кодировке DER структуры SubjectPublicKeyInfo ASN.1.
   • Описание лога, включая применяемые к логу политики и требования лога к сертификатам.
   • Максимальная задержка слияния (Maximum Merge Delay).
   • Набор доверенных корневых сертификатов.
   • Срок действия лога в виде [дата начала, дата окончания].
   • Cроки действия сегментированных логов (должны располагаться друг за другом без пробелов, каждый срок действия логов должен попадать в диапазон от 6 до 12 месяцев).
   • Будет лог отклонять истекшие и отозванные сертификаты или нет.

1. Принятые корневые сертификаты.

   Мы ожидаем, что CT-лог будет включать сертификаты удостоверяющих центров, которым Браузер доверяет по умолчанию на всех поддерживаемых платформах, включая Windows, macOS, Linux, Android, iOS.

   Также ваш лог должен принимать сертификаты, выпущенные Yandex’s Merge Delay Monitor Root, чтобы Яндекс мог проверять соответствие лога данной политике.

2. Отклонение сертификатов.

   Вы можете не включать сертификаты в CT-лог при определенных условиях, например, если у сертификата истек срок действия или на момент отправки он уже был отозван. Отклонение сертификата означает, что запись о нем не будет включена в дерево Меркла, даже если сертификат привязан к доверенному корневому сертификату. Отклоненному СT-логом сертификату SCT не выдается.

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

   Чтобы обеспечить гибкость и контролировать рост размеров CT-логов, новые CT-логи разделяются по диапазонам окончания срока действия сертификатов в виде [дата начала, дата окончания]. Это позволит CT-логу отклонять сертификаты, срок действия которых истекает за пределами указанного диапазона, разделяя набор общедоступных сертификатов, которые будет принимать каждый лог.

   Для этого:

   • Диапазоны истечения срока действия сертификатов для CT-лога должны быть не менее шести месяцев и не дольше одного календарного года.
   • CT-лог должен отклонять сертификаты, чей notAfter выходит за пределы диапазона окончания срока действия.
   • Количество сегментированных CT-логов должно охватывать период времени с настоящего момента на три-четыре года вперед. Многие считают удобным задавать годовые диапазоны, например Log2020, Log2021, Log2022, Log2023.

     По окончании диапазона сегментированные CT-логи будут удаляться из списка. В момент удаления владелец лога должен создать новый CT-лог, продлевая диапазон его действия. Например, при удалении Log2020 в начале 2021 года нужно подать заявку на включение в список Log2024.

4. Нарушения политики.

   Команда Яндекса проверяет CT-логи по своему усмотрению. CT-логи, нарушающие данную Политику, могут быть удалены из доверенного списка Яндекса в любое время.