Про поддержку Certificate Transparency для национальных сертификатов
Недавно мы рассказывали Хабру про поддержку в Яндекс Браузере тех сайтов, которые перешли на использование национальных TLS-сертификатов. Если вы пропустили, то рекомендуем прочитать пост, он содержит ответы на популярные вопросы.
Сегодня мы расскажем про следующий большой шаг в этом направлении — про обещанную поддержку публичных логов, созданных на базе открытого стандарта Certificate Transparency.
Краткая предыстория
Напомним, что с недавних пор российские организации и даже обычные вебмастеры всё чаще сталкиваются с невозможностью купить или продлить сертификат для сайта. Без действующего сертификата невозможно обеспечить безопасную передачу данных между сайтом и пользователями. Самоподписанные сертификаты — не выход по многим причинам: их нужно находить и устанавливать вручную, за ними нет никакого контроля, их используют злоумышленники для перехвата трафика.
Для решения проблемы был создан национальный удостоверяющий центр (НУЦ). Его сертификаты стали приниматься в Яндекс Браузере для сайтов из публичного белого списка. Это решение помогло не допустить ситуации, при которой пользователи лишились бы доступа к онлайн-сервисам или были бы вынуждены на свой страх и риск устанавливать сторонние корневые сертификаты на уровне всей системы.
На старте это решение работало так:
Владелец сайта запрашивает сертификат у НУЦ.
НУЦ проверяет права владельца и выпускает сертификат.
НУЦ добавляет домен сайта в публичный список по адресу gosuslugi.ru/tls.
Яндекс регулярно кэширует этот список на свои серверы, перепроверяет на ошибки, затем раздаёт всем копиям Яндекс Браузера.
Если сайт использует национальный сертификат, Яндекс Браузер проверяет, что его домен содержится в публичном списке, и только в этом случае устанавливает защищённое соединение. Если домена там нет, пользователь увидит стандартную ошибку про некорректный сертификат на сайте.
Быстрый для внедрения механизм. Но в долгосрочной перспективе непригодный. Причин несколько.
История знает немало случаев компрометации удостоверяющих центров. Например, в 2011-м злоумышленники взломали удостоверяющий центр Comodo, чтобы выпустить сертификаты для Gmail и других популярных сайтов. Чуть позже похожая проблема случилась у DigiNotar. Примерно тогда все в индустрии поняли, что время слепого доверия к подписям удостоверяющих центров прошло. Если сертификат был выпущен по ошибке, то у сообщества должен быть механизм узнать об этом. По этой причине белый список gosuslugi.ru/tls не подходит в качестве долгосрочного решения: в нём содержится лишь список доменов, но нет никакой информации обо всех выпущенных для них сертификатах. Это не прозрачно для сообщества.
Кроме того, у списка доменов есть и серьёзные технические ограничения. Любые изменения в списке нужно сначала скачать на наши серверы и проверить, затем каждая копия браузера должна скачать его у нас для локального хранения на устройстве. На всё это может уйти несколько дней, в течение которых сайт с новым сертификатом будет недоступен для пользователей. А ещё при существенном росте числа записей в списке возрастёт потребление трафика и памяти, что тоже может не обрадовать людей.
Мы не стали изобретать велосипед для этой задачи, а воспользовались уже принятым в индустрии открытым решением — стандартом Certificate Transparency.
Коротко про Certificate Transparency (CT)
Certificate Transparency предполагает создание публичных логов (CT-логов), в которых регистрируются выпускаемые сертификаты. Такие логи допускают только добавление записей. Если сертификат был выпущен по ошибке, то его можно только отозвать, но не удалить бесследно. Технологически это работает за счёт применения хэш-деревьев, как и в блокчейне. Верить этому не обязательно: CT-логи открыты для внешнего аудита. Это позволяет:
пользователям и браузерам — отслеживать выпуск всех сертификатов для домена и проверять их подлинность;
владельцам сайтов — обнаруживать несанкционированную выдачу сертификатов.
Работает это так:
Когда удостоверяющий центр (УЦ) регистрирует новый сертификат в CT-логе, в ответ он получает подписанную метку (SCT) этого сертификата. Каждый лог предоставляет свою метку.
УЦ передаёт заказчику сертификат. Метки логов содержатся в сертификате.
Когда браузер устанавливает соединение с сайтом, доверие к сертификату определяется не только доверием к УЦ, который выписал сертификат, но и по меткам CT-логов. К примеру, браузер Chrome при установке HTTPS-соединения требует, чтобы у сертификата было как минимум две любые метки от доверенных CT-логов.
Вот детальная схема с сайта проекта Certificate Transparency:
Как видно из схемы, доступность CT-логов для внешнего аудита — это ключевое свойство решения. Можно не полагаться на хэш-деревья, мониторить любые изменения в логах и сопоставлять изменения из разных логов.
Про CT-логи для национальных сертификатов
Чтобы вся эта схема работала, нужны CT-логи, которые будут записывать национальные сертификаты, выдавать для них подписанные метки. Они должны быть открыты для мониторинга. Должны иметь стабильный аптайм, хотя бы 99%. Один из примеров полного списка требований к логам можно найти на гитхабе. Там же есть готовый код, который позволяет поднять свой лог любому. На текущий момент ни один уже существующий CT-лог не принимает национальные сертификаты. Их поддержка — это вопрос договорённостей между владельцами логов и удостоверяющим центром. Будем надеяться, что в будущем такие договорённости появятся.
Яндекс разрабатывает Браузер, поэтому мы заинтересованы в появлении CT-логов, которые помогут защитить наших пользователей от компрометации сертификатов. Разработчики любого браузера в этом заинтересованы, поэтому, к примеру, компании Google и Apple создали и поддерживают свои логи. Мы пошли этим же путём и создали свой лог, воспользовавшись уже существующим открытым решением. Наш лог уже запущен и работает, НУЦ уже вносит в него новые сертификаты.
Свои CT-логи также запустили коллеги из VK Group и «Госуслуг». Технические адреса всех трёх логов с поддержкой национальных сертификатов можно найти по адресу https://browser-resources.s3.yandex.net/ctlog/ctlog.json. Этих данных уже достаточно для того, чтобы сообщество смогло читать логи, искать в них конкретные сайты и вести аудит всех изменений.
Со своей стороны мы также создали форму в Яндекс Вебмастере, которая упрощает получение информации обо всех выпущенных национальных сертификатах для конкретного сайта. Сейчас поиск идёт по CT-логу Яндекса, а также по белому списку доменов. В ближайшее время планируем начать искать и по другим CT-логам.
Про поддержку CT-логов в Яндекс Браузере
Мы уже добавили поддержку новых CT-логов в Яндекс Браузер для Windows, macOS, Linux, Android и iOS. Теперь мы прекращаем обновлять список доменов с gosuslugi.ru/tls, замораживаем состав этого списка на наших серверах. Примерно год он продолжит использоваться в Браузере для тех сертификатов, которые были выпущены по старой схеме (пока не истечёт их срок действия).
Для новых национальных сертификатов, выпущенных с поддержкой CT-логов, сейчас действует простое правило: Браузер принимает сертификат, только если для него есть подписанная метка CT-лога Яндекса. Это стартовое решение.
Дальше мы планируем запустить мониторинг сторонних CT-логов, чтобы убедиться в их работоспособности и стабильности. После этого начнём учитывать метки любых других логов национальных сертификатов. Мы открыты для поддержки новых CT-логов в Яндекс Браузере: достаточно соответствовать нашим техническим требованиям (вот-вот выкатим документацию). При этом политика ужесточится: Браузер будет требовать как минимум две метки, причём одну из них — обязательно от лога Яндекса.
Кроме того, мы готовимся выложить в опенсорс ту часть нашего Браузера, которая отвечает за поддержку сайтов и CT-логов с национальными сертификатами. Это может быть полезно не только со стороны аудита, но и тем командам, которые захотят добавить такую поддержку себе.
На всякий случай скажу, что нововведение никак не влияет на логику работы всех остальных (не национальных) сертификатов и их CT-логов. Для них мы, как и прежде, полагаемся на политики и списки из проекта Chromium.
Заключение
Поддержка сайтов с национальными сертификатами поможет не допустить ситуации, когда пользователи лишатся доступа к онлайн-сервисам или будут вынуждены устанавливать сомнительные корневые сертификаты на уровне всей системы. Прозрачность и открытость этого решения для пользователей, владельцев сайтов и разработчиков браузеров должны обеспечиваться строгим соблюдением правил Certificate Transparency. Хочется верить, что в будущем мы увидим не только новые CT-логи, но и новые инструменты для их удобного мониторинга. В этом нам нужна помощь сообщества.
Идеальных решений не бывает, поэтому повторю свой призыв из предыдущего поста: если вы знаете, как сделать лучше, — приходите, советуйте. Хотите покритиковать решения — критикуйте и предлагайте улучшения. Спасибо.
