dxdt.ru: занимательный интернет-журнал

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

Естественно, проверять наличие сертификатов в логах можно отдельно и другими программами. Главное – получить сам сертификат. В теории, если обнаружен сертификат с меткой, который, тем не менее, отсутствует в соответствующем логе, данный лог должен быть исключен из списка доверенных браузера. И это очень напоминает историю с удостоверяющими центрами TLS.

На тестовом сервере TLS 1.3, который я реализовал и некоторое время поддерживаю по адресу tls13.1d.pw, пришлось тоже перейти на TLS-сертификаты Let’s Encrypt. А это привело к замене цепочки с ECDSA на цепочку с RSA, что, конечно, не очень хорошо. Вообще, так как сервер экспериментальный и полностью самописный, замена сертификатов требует ручного вмешательства, поэтому “долгие” сертификаты удобнее, чем трёхмесячные. Но, в принципе, можно процесс автоматизировать.

Я как-то перестал описывать изменения тестового сервера на dxdt.ru: прошлая записка на эту тему датирована январём 2020 года. При этом сервер продолжают использовать, он даже помогает находить ошибки и неточности в реализациях TLS стороны клиента. Конечно, ошибки обнаруживаются и в самом сервере – их я стараюсь исправлять.

В ноябре 2012 года, десять лет назад, регистраторы RU-CENTER и R01 включили поддержку DNSSEC для имён в доменных зонах .su, .com, .net. В этом перечне важен домен .su – открытое внедрение DNSSEC в российских реестрах началось именно с него. А включение поддержки означало, что все клиенты даных регистраторов смогут настроить DNSSEC для своих зон. (К сожалению, за прошедшие десять лет слишком многое изменилось, а в результате перемен – утрачена масса полезных исторических веб-страниц, поэтому не могу привести ссылку на текст исходной новости; впрочем, копию пока что можно найти в web.archive.ru.)

Вообще, если посмотреть на сайт под доменом nox.su, то там сказано, что “криптографическая информация, соответствующая домену nox.su, внесена в файл зоны .su 23.11.2011” – то есть, ровно 11 лет назад и годом ранее, чем доступ к DNSSEC появился у упомянутых регистраторов. Это объясняется тем, что с nox.su мне помогли специалисты ТЦИ и RU-CENTER (большая им благодарность!): соответствующую DS-запись в реестр внесли, так сказать, в обход общедоступного интерфейса.

За эти годы DNSSEC не обрела особой популярности. Не только в российских доменах, но и во всей глобальной DNS. Сейчас в зоне .ru лишь около 6 тыс. имён с DS-записью (статистика по другим TLD – картину улучшает не сильно). В моде другие направления и другие этапы доставки данных, а в качестве едва ли не единственного метода защиты информации, на прикладном уровне, используется TLS.

Например, если говорить про DNS, то это DoH (DNS-over-HTTPS) и DoT (DNS-over-TLS). Естественно, эти технологии не позволяют, на уровне клиента, проверить подлинность данных именно DNS-ответа, однако делают возможной аутентификацию узла-источника, который эти данные принёс (DNS-резолвер), защищают канал передачи от прослушивания и подмены. Обычно, всё это доступно только на “последней миле” (то есть, от резолвера до клиента). Использование DoH/DoT не отменяет, конечно, возможности проверки DNSSEC, как и не решает основной задачи DNSSEC – подтверждения подлинности адресной информации.

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

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

Метку SCT выдаёт оператор CT-лога в ответ на добавление сертификата в лог. Когда Certificate Transparency первой версии только проектировали, то этот момент, к сожалению, не учитывали. Поэтому проявилась проблема “курицы и яйца”: чтобы выпустить сертификат с SCT-меткой – нужно получить метку, а чтобы получить метку – нужно выпустить сертификат (для того, чтобы отправить его в лог). В качестве некоторого “обходного решения” (“костыля” – скажут те, кто “хорошо в теме”) предложили ввести пресертификаты.

Пресертификат – он такой же, как и TLS-сертификат, но содержит специальное расширение (Poison), которое отмечено как критически важное (Critical), но при этом не должно распознаваться обычным валидатором. Хитрость, на которую делается расчёт, состоит в том, что, согласно рекомендациям, в случае обнаружения неизвестного расширения с флагом Critical процедура валидации должна считать сертификат не валидным. Все прочие поля пресертификата в точности совпадают с соответствующими полями сертификата, в этом весь смысл. Однако “отравленный” пресертификат как бы нельзя использовать на практике для аутентификации. И, обычно, это работает. Но, конечно, полагать, что все разнообразные валидаторы строго следуют рекомендациям по обработке расширений – слишком смело.

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

Впрочем, во второй версии Certificate Transparency от пресертификатов отказались – для размещения сведений о сертификате используются сообщения другого формата, их формирование не требует выпуска как бы настоящего, но “испорченного” сертификата.

Технический Центр Интернет (ТЦИ) открыл российский общедоступный удостоверяющий центр (называется “Центр сертификации”) TLS: https://tlscc.ru/ (бета-версия).

Центр позволяет выпускать TLS-сертификаты как с ECDSA, так и с ГОСТ-подписью. Чтобы заказать сертификат, требуется зарегистрироваться на сайте. Для подтверждения права управления доменным именем можно использовать DNS (размещается TXT-запись с кодом) или веб-сервер (публикуется текстовый файл). Однако нужно учитывать, что действующие корневые ключи УЦ не входят в дистрибутивы браузеров (возможно, пока что не входят), поэтому для использования сертификатов их придётся добавить вручную.

В продолжение предыдущей записки, про сертификаты от Let’s Encrypt. RSA и ECDSA – это распространённые в Интернете криптосистемы, которые используют различную математическую основу. ECDSA имеет целый ряд преимуществ. Однако в случае TLS-сертификатов существенный смысл в использовании ECDSA возникает тогда, когда вся цепочка сертификатов использует эту криптосистему.

Дело в том, что валидация (то есть, процесс установления подлинности) серверного сертификата подразумевает проверку подписи на одном или нескольких других сертификатах – это сертификаты удостоверяющих центров (УЦ). Технически, можно серверный (то есть, оконечный) сертификат с ECDSA-ключом подписать при помощи RSA. Именно так и делает Let’s Encrypt. При этом корневой доверенный сертификат с ECDSA у них уже есть, но вот оконечные сертификаты с ECDSA для обычных пользователей не выпускаются. Допускаю, что я не нашёл, где такую возможность включить, но, на мой взгляд, для оконечного сертификата с ECDSA автоматом должна выбираться вся цепочка с ECDSA – использование RSA, в этом случае, выглядит весьма странно (впрочем, учитывая, что сейчас 2022 год, RSA и в других случаях выглядит странно). Тем не менее, сертификат для dxdt.ru, который я вынужден был выпустить через Let’s Encrypt, содержит RSA-подпись. Ничего не поделать. Раньше, когда были доступны и другие УЦ, я использовал PositiveSSL, для которого есть ECDSA-цепочка.

Поскольку добывать платные долгоживушие сертификаты от “хорошо известных УЦ”, корни которых есть в браузерах, стало очень неудобно, да ещё и по совсем неадекватным ценам (это связано с общим современным состоянием интернетов и, в частности, применимо к российским пользователям и доменам внутри .RU), поменял сертификат dxdt.ru на Let’s Encrypt. В этом бесплатном УЦ пока что .RU не заблокировали. Не факт, конечно, что это надолго (не заблокировано), но там и сертификаты-то по три месяца. Кстати, довольно занятно будет, когда сертификаты .RU перестанет выдавать и Let’s Encrypt – почти вся зона .RU, в смысле веб-серверов, использует сертификаты именно этого УЦ.

При переходе на Let’s Encrypt удалось даже без проблем применить особый ключ ECDSA, который я специально подобрал (запись открытого ключа содержит некоторую hexspeak-подстроку в самом начале; если вы, вдруг, интересуетесь экзотической занимательной арифметикой на эллиптических кривых и умеете смотреть серверные ключи TLS-сертификатов (это несложно сделать браузером), то обратите, как говорится, внимание). Но всю цепочку в ECDSA Let’s Encrypt делать отказался – этим пришлось пожертвовать.

(Заметка первоначально опубликована в Facebook, 19/05/2020.) Я вот так устроил, что один сервис, проверяющий TLS, использует специально сконструированное сообщение ClientHello TLS 1.3 (см. скриншот) с посланиями внутри. Небольшая хитрость состоит в том, что там не только поля SessionID и ClientRandom с сообщениями, но и ключ для Диффи-Хеллмана (ECDH) на кривой P-256 – с посланием. Ключ – это два числа, но они должны задавать точку кривой, и хорошие реализации TLS проверяют, что ключ принадлежит кривой. Конечно, вычисление второй координаты Y по известной X-координате – никакой проблемы не составляет, но пришлось урезать пару символов, так как число приводится по порядку базового поля. У тех, кто знаком с ECDH, сразу возникнет вопрос – решил ли я попутно задачу дискретного логарифмирования для P-256? Но нет (а если бы решил, то сообщил бы об этом более занятным способом). Дело в том, что реально в этом сканере общий секрет не нужен, поэтому ответный ключ сервера просто игнорируется. (Конечно, вряд ли кто-то ещё это всё видит в трафике. Но при отладке – помогает.)

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

Традиционно, подобные механизмы “контролируемых утечек” в криптологии основываются на “порче” алгоритма вычисления псевдослучайных чисел (см. хрестоматийный пример про DUAL_EC DRBG). Так, в современных реализациях TLS сеансовый секрет вычисляется по алгоритму Диффи-Хеллмана (DH). Если в результате утечки третьей стороне станет известен клиентский секрет DH (то есть, секрет браузера), то эта сторона сможет вычислить симметричные ключи защиты трафика и всё расшифровать в пассивном режиме. При использовании “испорченного” программного генератора псевдослучайных чисел браузеру достаточно передать третьей стороне состояние генератора, в котором он находился перед тем, как были запрошены случайные числа для секрета DH. Генератор, естественно, детерминированный, поэтому, зная его полное состояние, нетрудно вычислить вывод (то есть, секрет DH). Грамотный подход подразумевает, что авторизованная третья сторона знает некоторый дополнительный ключ, который даёт гарантию, что раскрыть данные утечки сможет только эта сторона, а не всякий, кто разгадал алгоритм и записал трафик (именно так было сделано в DUAL_EC DRBG).

Утечку можно организовать самыми разными способами. Например, начальные сообщения сеанса TLS содержат случайные значения, которые, конечно, могут быть “не совсем случайными”. Более ловкие варианты основаны на манипуляции длиной сообщений (или пакетов данных), на передаче дополнительных параметров и так далее. Главное – каким-то способом поставить измеримую характеристику трафика в зависимость от состояния генератора псевдослучайных чисел клиента. Самое занимательное, что наличие такой зависимости может быть неплохо обосновано “желанием замаскировать метаинформацию о соединении”.

А использование подменного УЦ – это довольно грубый метод. Который, во-первых, требует активного перехвата соединения; во-вторых – оставляет надёжные, хорошо заметные следы.

На сайте ТЦИ опубликована моя статья, рассказывающая о технологии ECH (Encrypted Client Hello) и её, возможном, месте в современном наборе защищённых транспортов данных глобальной Сети. ECH – это развитие технологии ESNI, однако от ESNI всё ушло уже достаточно далеко.