Certificate Transparency в современном Интернете

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

Сейчас удостоверяющие центры TLS нередко называют Центрами Сертификации (ЦС). Это обозначение в чём-то точнее, — например, соответствующая роль как раз сводится к выдаче сертификатов после успешной проверки, то есть к сертификации, — а в чём-то расходится с традиционным для русскоязычной специальной литературы обозначением. Тем не менее на сами сертификаты терминология никак не влияет. С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье используется более привычное обозначение – Удостоверяющие Центры (УЦ).

Технология Certificate Transparency (CT) была предложена корпорацией Google в 2011-2012 гг. Формально данная технология предоставляет всем желающим возможность отслеживания деятельности Удостоверяющих Центров по выпуску TLS-сертификатов для веба. Это технология, не связанная с конечными интернет-узлами, которые используют сертификаты. Более того, один из важных аспектов CT – метки времени сервисов журналов сертификатов – предоставляет инструмент косвенной локальной проверки того, что данные конкретного сертификата, предъявленного сервером, были опубликованы в определённом журнале. Такую проверку может проводить браузер.

На практике большинство публичных глобальных журналов CT ведут сами крупные УЦ или организации, которые имеют собственный УЦ для веба, признаваемый распространёнными браузерами. Так, по состоянию на апрель 2023 года журналы CT, которые поддерживает браузер Google Chrome, принадлежат либо Google (корпорация имеет несколько собственных УЦ для TLS), либо другим крупным УЦ. Что, впрочем, не отменяет доступности мониторинга сертификатов, выпускаемых УЦ: журналы (далее – «логи») открыты для чтения и добавления сертификатов, соответствующих правилам. После внедрения корневого сертификата российского Национального Удостоверяющего Центра (НУЦ) в «Яндекс.Браузер» о поддержке отдельного набора логов Certificate Transparency и меток в составе сертификатов заявил «Яндекс». Это произошло в 2022 году.

Интересен «исторический контекст», в котором возникла сама технология CT. К 2011 году сформировался некоторый набор инцидентов, разной степени опасности и известности, связанных с выпуском и использованием тех или иных «подменных» сертификатов, которые были подписаны УЦ, признаваемыми браузерами. Конечно, для специалистов не было никакого секрета в том, что ключи и сертификаты УЦ могут использоваться (и используются) для прозрачного перехвата TLS/SSL, например, в составе специальных SSL-прокси. Однако в 2011 году направление обрело публичность и получило внимание СМИ. Наиболее шумной оказалась история с сертификатами, выпущенными в 2010–2011 годах в результате несанкционированного использования информационных систем удостоверяющим центром DigiNotar для доменов Google (*.google.com и др.) и многих других имен, в том числе соответствующих популярным интернет-сервисам.

Административные проблемы инфраструктуры УЦ TLS в вебе и в браузерах вызывали вопросы и раньше: так, удостоверяющих центров, которым доверяют браузеры, очень много, но каждый из них может выпустить сертификат для произвольного домена – согласие администратора домена, естественно, строго прописано в правилах, но технически не требуется. Типовой браузер «из коробки» признает такой «подменный» сертификат валидным, а значит – третья сторона сможет самым простым и грубым способом перехватывать содержание веб-трафика. Пользователь не имеет возможности стандартными средствами отличить нелегитимный сертификат, самовольно выпущенный УЦ, от легитимного, который заказал администратор домена. Для борьбы с такой угрозой ещё в 2010 году начали предлагать разные технологии, полагавшиеся на хорошо зарекомендовавшие себя в смежных областях способы управления доверием ключам.

Например, технология DANE (DNS-Based Authentication of Named Entities, в дословном переводе – DNS-аутентификация именованных сущностей) предлагала размещать отпечатки криптографических ключей или сертификатов сервера непосредственно в DNS-записях: клиент может извлечь такие записи из DNS и сравнить данные с тем, что передаётся в сертификате в рамках конкретного соединения. Если перехватывающая сторона не может подменить DNS-трафик, то подмена сертификата тут же станет явной: его отпечаток не совпадёт с отпечатком из DNS (это обязательно так, поскольку подменный сертификат должен, как минимум, содержать другое значение криптографического ключа сервера). От подмены же DNS-трафика должна защищать технология DNSSEC.

К сожалению, в вебе никакого распространения DANE не случилось. Эта технология продолжает использоваться сейчас, но обычно для почтовых серверов и других сервисов, а вот популярные браузеры DANE не поддерживают, как не стали они поддерживать и какие-либо другие технологии ограничения возможностей по подмене криптографических ключей, доступные администраторам веб-узлов. (В качестве дополнительного примера - HTTP-заголовок Public-Key-Pins, который концептуально совпадает с методом запоминания ключей «при первой встрече», использующимся, например, в SSH.) Вместо внедрения полностью распределённых инструментов подтверждения отпечатков ключей Google предложила достаточно централизованную схему Certificate Transparency.

Журналы Certificate Transparency содержат сертификаты (с некоторыми особенностями, о которых позже) и дополнительную информацию, определяющую место данного сертификата в журнале – это позволяет один сертификат добавлять только один раз, фиксируя время добавления. Основная особенность журнала CT в том, что он, как сервис, работает только на добавление и чтение. Проверить целостность записей и корректность структуры лога можно снаружи. Для этого нужно знать открытый ключ лога: он позволяет проверить криптографические доказательства наличия записей, предъявляемые сервисом в ответ на запрос. Доказательства связаны одно с другим и образуют древовидную структуру (дерево Меркла), построенную с использованием хеш-функции. Это дерево упрощает аудит и, таким образом, создаёт основу для защиты от изменения данных постфактум. То есть администратор некоторого домена может периодически просматривать логи CT на предмет того, не был ли выпущен без его ведома сертификат. С другой стороны, TLS-клиенты, различные сканеры, могут добавлять в логи сертификаты, обнаруженные на TLS-узлах.

Заметьте, что здесь не идёт речи о защите «транзакционного дерева» от изменения через сложность _предварительного_ вычисления некоторого значения, как это делается в случае криптовалютных «блокчейнов». Считается, что состояние защищённости лога CT создаётся самой возможностью проведения аудита, который выявит неминуемые изменения (вычислительно сложно сгенерировать новое, по составу узлов, дерево, которое даст те же последовательности отпечатков).

Всякий желающий может просмотреть записи лога CT и проверить, что данные об отдельных элементах сходятся с точки зрения структуры дерева. Для поиска по данным логов есть открытые веб-сервисы: самый известный из них – crt.sh. Именно на основе программного обеспечения crt.sh построен сервис для просмотра российских CT-логов, запущенный ТЦИ: ct.tlscc.ru.

То, что данные лога нельзя изменить постфактум так, чтобы никто этого не заметил, – фундаментальная особенность. Естественно, это работает только в том случае, когда за логами следят независимые аудиторы, обменивающиеся между собой информацией. Каких-то «самосбывающихся» ограничений, - как в случае, например, с Биткойном, - в Certificate Transparency не предусмотрено: эта технология о другом – она лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне. То есть, несмотря на расхожее неверное представление, не только наличие логов, но и широкая поддержка Certificate Transparency никак не гарантируют того, что УЦ не выпустит сертификат в обход заявленных политик и правил проверки.

Более того, даже эффективное использование CT для наблюдения требует дополнительных допущений. Прежде всего, должна как-то гарантироваться полнота логов: действительно, откуда сторонний наблюдатель знает, как и какие сертификаты попадают в лог? В Certificate Transparency нет механизма обеспечения полноты. Оно и понятно: технология разрабатывалась в условиях, когда полноты логов не могло быть в принципе, – предлагался инструмент для публикации сертификатов, которые удалось обнаружить на веб-узлах. Первый из опубликованных журналов CT вообще был заполнен сертификатами, которые собрали с веб-узлов роботы Google. Функция добавления сертификатов непосредственно в момент выпуска появилась позднее. А введение требования обязательности публикации в логе привело к добавлению искусственного, противоречащего практике внутренней работы УЦ обходного механизма: несмотря на то, что CT позиционировалась как инструмент противодействия выпуску «лишних» сертификатов, после внедрения технологии от УЦ потребовали каждый раз выпускать дополнительный сертификат на то же имя только для того, чтобы включить его в лог. (Такие сертификаты назвали «пресертификатами». Они имеют одно техническое отличие от «основного» сертификата, о чем рассказано подробнее ниже. Пресертификаты исключены только во второй версии CT, которая пока что далека от повсеместного внедрения.)

Нельзя не отметить, что с историей применения CT связан ряд достаточно громких событий в области деятельности Удостоверяющих Центров TLS. Например, в 2017 году данные из логов CT послужили доказательством того, что УЦ Symantec выпустили очень много сертификатов с грубым нарушением политик, что в итоге привело к удалению этого УЦ из списка доверенных в браузерах. В том же году данные CT стали основой целого технического расследования в отношении УЦ WoSign, который был замечен в выпуске сертификатов со сдвинутым в прошлое интервалом валидности (backdate), что является серьёзным нарушением общепринятых принципов работы УЦ. По этой и другим причинам корневые ключи WoSign потеряли статус доверенных в распространённых браузерах. В 2019 году при помощи CT обнаружили нарушения, допущенные УЦ Certinomis (что также привело к отказу в доверии). В условиях работы многих УЦ, при наличии действенных административных инструментов влияния на деятельность этих УЦ, Certificate Transparency может оказывать эффективную техническую поддержку для процесса контроля, но не следует преувеличивать значение самой этой технологии, взятой, так сказать, в вакууме.

Вернёмся к сервисной части. Предполагается, что логи CT открыты на добавление для всех, но при этом есть ограничение по списку корневых ключей УЦ, сертификаты от которых принимаются в данный лог. Это, например, позволяет побороть возможное замусоривание лога фиктивными сертификатами, так как в процессе добавления проверяются подписи на сертификатах и цепочка доверия. Включение сертификата в дерево также подтверждается подписью, но это уже подпись от ключа лога – с каждым логом связан публичный криптографический ключ, который позволяет идентифицировать лог и подтвердить, что опубликованные данные действительно обработаны данным логом.

У лога есть оператор. Лог обрабатывает и публикует сертификаты для многих доменов от многих УЦ. В общем случае участие УЦ и участие администраторов доменов для работы лога не требуется – достаточно компании-оператора. Всё это повышает уровень централизации. В CT некоторую степень «распределённости» гарантирует то, что аудит логов могут производить самые разные стороны. Но, во-первых, таких сторон должно быть много, их выводы кто-то должен принимать как руководство к действию, а во-вторых, с введением понятия «доверенного лога» в браузеры смысл мониторинга всех прочих логов поменялся.

Можно потребовать, чтобы для признания сертификата валидным сведения о нём были опубликованы в логе CT. Более строгое требование – сведения о включении в лог должны быть в составе самого сертификата. Последний случай позволяет административными мерами вынудить УЦ добавлять сведения о всех выпускаемых сертификатах. Со стороны того или иного оператора лога подтверждение, что сертификат был предъявлен, может быть оформлено в виде метки времени с подписью – такая метка является своего рода обязательством включить сертификат в лог. Эта метка добавляется в сертификат, и если браузер обнаружил метку и она оказалась корректной, соответствующей ключу доверенного лога, то сертификат признаётся валидным. Это снимает проблему постоянных обращений к логам, которые потребовались бы, если бы браузер проверял встреченные на просторах веба сертификаты непосредственно на лог-сервисах CT (и тут нельзя забывать, что происходила бы утечка информации о посещаемых сайтах).

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

Пресертификат отличается от «полноценного» сертификата только тем, что содержит специальное расширение-флаг, которое должно предотвратить его практическое использование. Такое допущение основано на свойствах типового алгоритма валидации сертификатов: спецификации предписывают, буквально, что при обнаружении в составе сертификата расширения неизвестного типа, помеченного как критическое (Critical – формат TLS-сертификатов предоставляет возможность присвоения статусов и известным, и неизвестным расширениям), сертификат должен признаваться невалидным. То есть, если проверяющая программа знает, что обнаруженное poison-расширение – это расширение, обозначающее пресертификат, то она не станет этому пресертификату доверять, так как пресертификаты – это не сертификаты. А если программе poison-расширение, как тип, не известно, то она опять же не должна доверять сертификату, поскольку встретила неизвестное критическое расширение. Конечно, несколько наивно предполагать, что все разнообразные валидаторы сертификатов умеют обрабатывать расширения должным образом, но для современных браузеров такой подход должен был сработать.

Сертификат, парный к пресертификату, совпадает с последним почти во всех полях, за исключением наличия SCT-меток, отсутствия poison-расширения и другого значения подписи. У сертификата и пресертификата – одинаковые серийные номера. Уже только этот факт грубо противоречит практике работы УЦ TLS, так как предписано, что один УЦ не должен выпускать два сертификата с одинаковым серийным номером – это довольно серьёзное нарушение общепринятых правил. Отход от него, как минимум, ведёт к существенному изменению логики работы внутреннего программного обеспечения удостоверяющего центра: изменения внести можно, но разработчики-пуристы рискуют испытать сильное психологическое потрясение, и у некоторых начнёт дёргаться глаз. Тем не менее сертификат для получения SCT-меток назвали «пресертификатом», что и позволило закрыть глаза на отход от одного из ключевых принципов. Надо заметить, что полностью свыкнуться с противоречием всё же не удалось – в Certificate Transparency версии 2.0 от пресертификатов отказались.

Итак, получение SCT-меток позволяет браузерам дополнительно проверять CT-статус сертификата. Например, этот метод заявлен в «Яндекс.Браузере» для сертификатов российского Национального Удостоверяющего Центра (НУЦ): для доверия TLS-сертификату, выпущенному НУЦ, требуется метка от CT-лога «Яндекса» (и дополнительные метки других доверенных логов). Браузер Google Chrome требует наличия SCT-меток от известных доверенных CT-логов в большинстве случаев валидации.

Нередко приходится слышать, что наличие SCT-метки гарантирует, что сведения о сертификате включены в лог и, таким образом, опубликованы. Это не так. SCT-метка – это, в лучшем случае, подтверждение того, что оператор лога, владеющий соответствующим секретным ключом, видел сертификат. И, вообще говоря, для генерирования валидной SCT-метки достаточно знать секретный ключ лога и сам сертификат: метка никак не привязана к другим данным из лога. Конечно, если известен сертификат, то проверять его наличие в логах можно отдельно и другими программами. Практика применения подразумевает, что если обнаружен сертификат с меткой, который тем не менее отсутствует в соответствующем логе, то данный лог должен быть исключен из списка доверенных браузера, поскольку лог нарушает правила CT. Однако это чисто административная задача: никаких технических инструментов, которые делали бы другие метки «неправильного лога» невалидными в CT, опять же, не предусмотрено.

Получается, что даже внедрение контроля CT-логов в браузер приводит лишь к тому, что для выпуска подменного сертификата нужен доступ к ключам УЦ и дополнительно к ключам доверенных логов. Если доверенный лог всего один, то это означает, что нужен лишь ещё один ключ и участие ещё одной организации – оператора лога. Да, добавление ещё одного участника в процесс выпуска валидного сертификата улучшает ситуацию с точки зрения безопасности, но при отсутствии каких-либо других технических препятствий практическую эффективность этого добавления нужно оценивать, исходя из административных особенностей процесса. А они могут быть самыми разными.