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

Даниэль Бернштейн (Daniel Bernstein) опубликовал сводную страницу (англ.) с информацией о “структуре спора” в IETF, который спор уже некоторое время идёт вокруг спецификаций, предлагающих использование в TLS негибридных криптосистем с постквантовой стойкостью (а именно – ML-KEM без дополнительных классических схем). Письма от Бернштейна, в рамках этой дискуссии, даже поставили на отдельную премодерацию в списках рассылки IETF – то есть, ограничили возможность что-то публиковать в этих списках. Там, на странице, предполагается, что продвижение негибридных вариантов ML-KEM через IETF – это “атака со стороны АНБ на уровне спецификаций”. Основные пункты, в поддержку и против, – организованы в виде дерева ссылок, по которому несложно понять, какие идеи/возражения есть, как они продвигаются; что весьма содержательно даже само по себе.

Например, есть интересный момент о том, что спецификации IETF не должны влиять на “внутренние реализации TLS”, потому что смысл деятельности IETF состоит в разработке спецификаций для Интернета в целом. Это в качестве ответа на предположение, что возможность “сломать совместимость TLS”, оставив там только негибридные схемы ML-KEM и полностью убрав ECC, не повлияет на “внутренние реализации”, где, мол, такое могло бы использоваться. Тут фокус в том, что спецификация TLS 1.3 делает поддержку криптосистем на эллиптических кривых обязательной, поэтому реализации, в которых такой поддержки нет (типа, для “экономии ресурсов”), не соответствуют спецификации (это будут дефектные реализации). Поэтому внедрение негибридных криптосистем, при наличии гибридных, – реально усложняет TLS (отмечу ещё раз, что TLS 1.3 – гораздо понятнее и логичнее, чем предыдущие версии спецификаций TLS; и странно это редкое для IETF преимущество ломать).

Не менее занимательно и странное утверждение в поддержку негибридных систем, основанное на размере ключей: мол, “отказ от части ECC в гибриде экономит место для ключей, что актуально для сред, где вычислительные ресурсы сильно ограничены”. Это странно потому, что, например, ключ ML-KEM имеет размер более килобайта (1184 байта), а та же схема X25519 (ECC) добавляет к ним только 32 байта. То есть, как справедливо замечено в возражении: “затраты на передачу и вычисление части X25519 пренебрежимо малы в сравнении с затратами на передачу ключей и шифротекста ML-KEM”. И верно: не нужно же забывать про чисто сетевые затраты, поскольку отправка и получение нескольких килобайт по TCP – это затраты на формирование заголовков пакетов, на копирование массивов, – которые, по размеру, будут за пределами возможностей быстрого преобразования, – затраты на переключение контекста, и так далее; поэтому разница в вычислениях между длиной 32+32 байта и длиной 1184 + 1568 байтов – может быть весьма разительна на некоторой аппаратуре, особенно, если говорить о средах с малой вычислительной мощностью.

В Let’s Encrypt собираются внедрить (англ.) новый метод проверки права управления доменом (DCV), который, при помощи публикации специальной TXT-записи, привязывает DNS-зону к ACME-аккаунту, а не к коду валидации, и при этом такая привязка становится “постоянной” – видимо, с точностью до того, как сервер будет запрашивать TXT-записи и фиксировать факт удаления соответствующего кода. Метод называется DNS-PERSIST-01.

Довольно занятное начинание. Например, в описании от Let’s Encrypt (по ссылке выше) имеется пространная “мотивировочная часть”, где несколько раз утверждается, что, мол, “во многих конфигурациях реквизиты доступа к DNS API распределяются через “пайплайны” выпуска и обновления [сертификатов], увеличивая количество мест, в которых атакующий может их [реквизиты] скомпрометировать”. Так, конечно, делать нельзя – нельзя раздавать реквизиты доступа к DNS “пайплайнами” по многим местам – ACME этого не требует. Но забавный момент тут в другом: предлагаемая схема, предположим, уходит от “раздачи реквизитов” от DNS, но зато привязывает всю защиту и безопасность к ключу от ACME-аккаунта!

То есть, ACME-аккаунт в этой схеме строго привязывается к DNS-имени, поэтому, если атакующая сторона получила доступ к ACME-аккаунту, то доступ к DNS уже вообще не нужен. Многие ли DevOps и системные администраторы вообще знают, что в ACME-клиенте есть секретный ключ от аккаунта, которым подписываются запросы, и о том, где этот ключ хранится? Не раздаётся ли этот ключ через “пайплайны” по резервным копиям? Вопросы, впрочем, риторические. Но должно же быть очевидно, что замена одной потенциальной “точки взлома” (доступы к DNS) на единственную другую (ACME-ключ клиента) – не даёт каких-то новых преимуществ с точки зрения безопасности. Но нет – приводят в пример. (Все эти моменты, кстати, описаны в черновике RFC для DNS-PERSIST-01. Но это – и черновик, и вряд ли многие прочитают.)

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

И если, на практике, на стороне, которая заказывает TLS-сертификаты, управление DNS ещё как-то понятно администраторам, то ACME-клиент – совсем мутная вода.

Естественно, для того, чтобы публиковать коды ACME-подтверждения в DNS, не требуется раздавать реквизиты от этой DNS по куче мест. То есть, понятно, что такое регулярно происходит на практике, тут у Let’s Encrypt всё верно написано: это, как раз, один из побочных эффектов всей этой “автоматической истории” с ACME – раскидывание CNAME и тому подобные нехорошие варианты. Но управление DNS проще реализовать правильно и надёжно, чем управление ACME-клиентом: например, машина, которая является источником обновлений DNS-зоны, может сама ходить за кодами на точку раздачи, подтверждая потом публикацию ACME-клиенту, и так далее – вариантов много. В теории, наверное, и для ACME-ключа можно придумать серьёзную защиту. Проблема тут совсем в другом: многие знают, что DNS нужно защищать, а то будут проблемы; о том, что защищать нужно ACME-аккаунт – ну, может, кто-то и подумал, но даже если и подумал, то, скорее всего, решил: “а зачем? всё равно же DNS-доступ нужен для выпуска сертификата”. И не забывайте, что доступ к DNS, действительно, всё так же позволяет выпустить TLS-сертификат, только теперь ещё и доступа только к ACME-аккаунту становится достаточно.

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

(Конечно, у меня есть планы по развитию этого описания. Например, планирую добавить подробный разбор схем согласования ключей, в том числе, с постквантовой криптосистемой ML-KEM. Примеры устройства хеш-функций. И так далее. Планы-то есть, а вот ресурсов – пока не хватает. Но посмотрим. Возможно, в следующем году.)

В продолжение предыдущей записки. Ещё один занятный момент про сверхкороткие TLS-сертификаты.

Понятно, что если сертификаты действуют недолго, то на заданном интервале времени сертификатов будет больше. Например, больше сертификатов будут попадать в логи Certificate Transparency (CT-логи). Возникнет дополнительное зашумление: если для домена example.com за месяц выпущено десять сертификатов вместо двух, как раньше, то запутаться с обработкой и мониторингом проще.

Если вы вдруг посчитали, что этот эффект надуман, да и вообще – быть такого не может, чтобы мониторы CT-логов что-то потеряли, то вспомните недавнюю весьма странную историю с сервисом 1.1.1.1 и Cloudflare. В той истории CT-логи непосредственно самой корпорации Cloudflare получили от внешнего удостоверяющего центра (УЦ) информацию о том, что – без санкции Cloudflare! – этим УЦ выпущены TLS-сертификаты для 1.1.1.1 (а это важнейший сервис Cloudflare), но даже корпорация Cloudflare, – без всякого сраказма: технологический лидер направления, – целый год ничего подозрительного в тех самых своих CT-логах каким-то образом не замечала. А теперь представьте, что сертификатов стали выпускать в десятки раз больше.

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

Сейчас тут обычно приводят в качестве препятствия всё ту же технологию Certificate Transparency. И действительно, если клиент проверяет метки CT (SCT) в сертификатах, то эти метки должны быть и в подменном сертификате. Вот только получение меток не требует размещения сертификата в публичных логах. Это, как раз, очень распространённая ошибка – считать, что SCT-метки гарантируют размещение в логах. Нет. Для вычисления валидной метки нужен только сам сертификат и секретный ключ оператора CT-лога. Так что, для подменного сертификата, могут генерироваться только метки, без размещения в логах. Это будет нарушением соглашений с браузерами. Но, как бы, в CT-логах, как мы только что выяснили, и так много “коротких” сертификатов для разных имён, и за ними никто особо не следит.

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

Основных признаков – два: быстрое сокращение допустимого срока действия TLS-сертификата и отказ от механизмов отзыва. По срокам действия: уже принят план, по которому к 2029 году максимальный срок действия валидного сертификата не должен превышать 47 суток. “Валидного” – означает, что сертификаты, в которых указан более долгий срок действия, будут автоматически считаться клиентом невалидными, только на основании этого срока действия, вне зависимости от того, сходится подпись удостоверяющего центра (УЦ) или нет. Скорее всего – максимальный срок действия ещё заметно подсократят, не дожидаясь 2029 года.

Отказ от механизмов отзыва: в предельном случае – просто не будет способа отозвать сертификат. Получаем безотзывный токен. Это уже так для сверхкоротких сертификатов (со сроком действия меньше десяти дней). Сейчас для публикации статуса выпущенных сертификатов (действует/отозван), как минимум, есть списки отзыва (CRL). Следует ожидать, что для сертификатов-токенов – ничего подобного не будет.

Итак, представим, что TLS-сертификаты для доменных имён и IP-адресов выпускаются со сроком действия три дня максимум (сейчас уже есть шестидневные сертификаты). Что это означает с технической точки зрения? Например, штатно работающий браузер не станет показывать пользователю контент на веб-сайте, у которого, – внимание! – на сервере не установлен TLS-сертификат с подходящим сроком действия (до подписей мы ещё не добрались даже).

Тут можно возразить, что браузер и так имеет возможность заблокировать любой сайт, просто по имени хоста сервера, по URL, ещё как-то. Получается, ничего нового, в плане возможностей, для пользователя и браузера не появляется. Это не совсем так.

Прежде всего, чтобы подобная фильтрация работала в браузере – нужно, чтобы разработчики браузера обеспечили хранение где-то списка веб-узлов, к которым браузеру нельзя подключаться. И этот список – нужно либо передавать в конкретные экземпляры браузера целиком, либо обеспечивать онлайн-интерфейс (такие схемы есть и иcпользуются: см. Safe Browsing и т.д.). В случае же с TLS – получение нужного токена полностью уходит на сторону веб-сервера (понятно, при периодическом участии УЦ). То есть, схема оказывается “открытой” и поэтому не требует ресурсов на перечисление узлов и построение списков: всё работает в другую сторону и вместо внесения в список запретов – веб-узлу требуется самостоятельно получить разрешение на доступ.

И, ещё раз, не следует забывать и о том, что TLS – это далеко не только веб. Однако принципы валидации из веба и веб-браузеров, обычно, позже распространяют и на другие сценарии использования.

Чтобы получить сертификат, разрешающий доступ, сервер должен обратиться к тому или иному УЦ. Понятно, что обновление сертификатов раз в несколько дней означает, что это обновление должно происходить автоматически. Да, есть протокол автоматизации ACME, а получение сертификата можно встроить непосредственно в веб-сервер. Что получается? Получается, что веб-сервер периодически отмечается в некотором центральном сервисе (ACME-УЦ), который выдаёт токен (сертификат), подтверждающий обращение и предназначенный для предъявления клиентам, которые подключаются к этому веб-серверу. Если токен-сертификат получить не удалось, пользователи к веб-сайту подключиться не смогут. Как только токен стал короткоживущим – мы получили не просто схему аутентификации узла, но и схему авторизации доступа, в которой роль авторизующей стороны играет удостоверяющий центр. Безотзывность токена нужна тут для того, чтобы не тратить ресурсы на сопровождение механизма отзыва, который с необходимостью будет “разбухать”: ведь токены выпускатся очень часто.

Можно возразить, что, мол, за вычетом отзыва, всё так было и раньше: если мы хотим, чтобы доверенным образом работал HTTPS, то всё равно нужно было получать сертификат от УЦ. Но в этой “старой схеме” и сертификат действовал, предположим, год, и получение нового сертификата не было встроенно в веб-сервер. То есть, техническая конфигурация становится совсем другой.

Конечно, у схемы с короткоживущими токенами доступа вместо TLS-сертификатов есть свои преимущества: например, её можно быстрее адаптировать к изменениям в составе криптосистем или к изменениям в формате сертификата. Но не следует забывать, что такая схема приносит с собой совсем новую парадигму управления доступом.

Let’s Encrypt начали поэтапно сокращать максимальный срок действия выпускаемых TLS-сертификатов с 90 дней (как сейчас) до 45 дней (в 2028 году обещают). Так что, скорее всего, браузеры тоже подтянутся и – сокращать срок действия придётся всем остальным УЦ. Сертификаты движутся по пути превращения в короткоживущие токены, разрешающие клиентам доступ к веб-ресурсу.

Кстати, так как SCT-метка в сертификате – это только дополнительная подпись, то возможность взламывать криптосистему подписи позволяет сгенерировать и TLS-сертификат, и валидную SCT-метку в нём. Логи Certificate Transparency тут никак не мешают.

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

Естественно, зная секретный ключ УЦ, можно просто пойти и получить валидную SCT-метку непосредственно от оператора CT-лога, не взламывая ключи этого оператора. Но, предположим, тогда (пре)сертификат всё же будет опубликован.

Что это означает? Это означает, что возможность глобально ломать ECDSA никак CT-логами не блокируется. Почему-то про это постоянно забывают.

Пишут про метод, позволяющий обнаружить характер сообщений, которыми обмениваются пользователи с LLM через интерфейсы, использующие TLS. Там нет никакой уязвимости TLS, а речь идёт про анализ метаинформации о соединении: свойства потока TLS-пакетов, выдаваемых интерфейсом LLM, коррелируют с потоком токенов, генерируемых моделью; соответственно, зная примерные характеристики потоков токенов, выдаваемых по “чувствительным темам”, можно попытаться обнаружить факт обсуждения таких тем по TLS-трафику. Это давно известная особенность TLS-соединений. Работает не только для LLM, но и для прочих веб-интерфейсов приложений.

Процитирую фрагмент по этой теме из моего технического описания TLS:

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

Cloudflare собираются вместе с Google тестировать новый формат TLS-сертификатов в браузере Chrome. Это сертификаты, в которых вместо значения подписи размещается доказательство принадлежности к дереву Меркла (дерево хешей), где соответствующий корень подписан удостоверяющим центром (УЦ). Это принципиально иная структура, по сравнению с действующей в TLS для веба сейчас. Подписи не будет в оконечном сертификате, но зато и проверять в типичном сценарии нужно меньшее количество подписей. Схема хорошо подходит для криптосистем с постквантовой стойкостью: в этих криптосистемах запись значения подписи часто требует много байтов, а использование дерева позволяет эти значения не передавать вместе с каждым сертификатом. При этом хеш-функции, в целом, считаются достаточно стойкими к гипотетическим атакам на квантовом компьютере. Стойкость доказательств, использующих дерево Меркла, основана на стойкости хеш-функций (помимо подписи, конечно).

То есть, если схему упростить, то УЦ выпускает сертификаты пачками, объединяет их в дерево Меркла и подписывает корень. Схема аналогична тому, как устроены логи Certificate Transparency. Сторона, проверяющая такие сертификаты, должна считать доверенным подходящий корень дерева: то, что значение конкретного сертификата сходится к нужному корню – проверяется путём вычисления значений хеш-функций от сертификата и от вершин, поддерживающих путь к корню; нужные для проверки значения хеш-функций как раз и передаются вместо подписи в сертификате. По ссылке выше есть картинки, объясняющие принцип.

Это пока что эксперимент. В роли тестового УЦ, выпускающего сертификаты “деревьями Меркла”, выступит Cloudflare. Но обещают, что это будет не полноценный УЦ, а только сервис, просто укладывающий “в дерево” уже выпущенные действующим доверенным УЦ сертификаты. Соответствие сертификатов разных типов станет проверять Google, прежде чем раздавать в браузеры соотвествующие “корни доверия”. Обратите внимание, что тут речь про корни в терминах схемы с деревьями Меркла: это совсем не то же самое, что корневые ключи УЦ – ключи УЦ остаются, в том числе, корневые, но они здесь используются для проверки подписей на корнях дерева, охватывающего некоторый набор сертификатов. В разрабатываемой схеме, вообще говоря, будут не просто корни, а некоторые опорные узлы, позволяющие дереву расти. Возможно, я напишу отдельную подробную записку про эту технологию, которая технология, кстати, полностью поменяет имеющуюся сейчас инфраструктуру УЦ для веба. Поменяет уже на техническом уровне. В общем, довольно интересное развитие истории с TLS-сертификатами.

Что-то опять довелось услышать сравнение аутентификации в SSH (по ключам) и двусторонней аутентификации в TLS (HTTPS) по сертификатам: мол, и там, и там – есть секретные ключи, которые нужно передавать для организации работы приложений, так что это одно и то же с точки зрения эксплуатации системы. Но это не так. Ситуации SSH и TLS тут различаются принципиально.

Посудите сами. Речь тут идёт о типовой схеме с SSH-ключами (в SSH тоже можно сделать “сертификаты”, но сейчас не об этом). Итак, в SSH имеем аутентификацию по отпечаткам ключей каждой стороны: сервер, фактически, проверяет отпечаток (то есть, значение – не важно) открытого ключа клиента; а клиент – отпечаток открытого ключа сервера. Стороны аутентифицируют каждая каждую напрямую, без помощи третьей доверенной стороны. Если ключ скомпрометирован, то его нужно непосредственно исключить по значению из списка доверенных. Например, удалить на сервере из authorized_keys.

При этом список доверенных ключей каждая сторона ведёт собственный (да, могут быть вспомогательные механизмы автоматического добавления снаружи и, также, внешней проверки, но штатный способ – собственная, локальная проверка). Включение в список доверенных ключей выполняется с участием администратора. На клиенте, нередко, добавление выполняется автоматизированно, при первом соединении (но не всегда так). Да, тут есть проблема, что многие администраторы и DevOps сейчас, подобно пользователям браузеров, начинают привыкать к игнорированию сообщений о добавлении новых отпечатков в доверенные. (Но действующую подмену, вообще говоря, в правильно настроенном SSH-клиенте проигнорировать сильно сложнее, чем в браузере.)

Теперь TLS. Двусторонняя аутентификация: серверный и клиентский сертификаты. Тут обязательно участвует третья сторона: штатный способ аутентификации – проверка подписи на сертификатах ключей. Технически, можно сравнить отпечатки (key pinning и пр.), но это будет за рамками типовой схемы. Типовая же схема требует сравнения не отпечатка, а подписи, поставленной третьей стороной. Совсем другая история, по сравнению с SSH. Именно что от слова “совсем”. Тут уже нельзя “отключить ключ” клиента или сервера, просто удалив его из списка доверенных. А если нет способа внешней проверки статуса сертификата и способа отзыва сертификатов, то всякий действующий (по времени) сертификат с верной подписью удостоверяющего центра будет всегда принят стороной, проводящей проверку. Подпись известного удостоверяющего центра верна? Верна. Принимаем. Без вариантов.

Если секретный ключ от клиентского сертификата утёк вместе с сертификатом, то тот, кто увёл ключ и сертификат, сможет предъявить этот сертификат серверу и пройти аутентификацию. Без отзыва сертификата – сервер ничего не может поделать: нет у него способа проверить, что это какой-то скомпрометированный ключ. Заметьте, что именно поэтому механизм отзыва тут строго необходим (ну, либо, можно увязнуть в новомодных тенденциях: сертификат должен быть сверхкороткого действия; что, естественно, никак не отменяет невозможность “отключения” доступа для всё ещё действующего сертификата, только интервал времени для успешной атаки уменьшается, это да).

В схеме SSH, чтобы подставить ключ на сервер – нужно прописать его значение в файл на сервере. В схеме с TLS-сертификатами – нужно подписать сертификат на стороне УЦ. На сервер, которому будет предъявлен валидный сертификат, даже не потребуется заходить.

Так что подходы к аутентификации в SSH и TLS (по сертификатам) – совершенно разные, нельзя их смешивать.

В Cloudflare выпустили разбор ситуации с выпуском неавторизованных TLS-сертификатов для 1.1.1.1. Пишут, что в логах Certificate Transparency (CT) эти TLS-сертификаты не обнаружили потому, что не отслеживались сертификаты для IP-адресов, в мониторинг приходило слишком много сообщений из CT, а также и не для всех доменов/ресурсов настроили отслеживание сертификатов.

В общем – не следили за сертификатами в CT-логах, несмотря на наличие соответствующего собственного сервиса. Ситуация “сапожник без сапог” – не редка в корпорациях, и, к сожалению, настигла Cloudflare тоже. Но тут, как минимум, оперативно выпустили подробный разбор случившегося.