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

Выпустил очередную, – ежегодную, – версию технического описания протоколов 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 году обещают). Так что, скорее всего, браузеры тоже подтянутся и – сокращать срок действия придётся всем остальным УЦ. Сертификаты движутся по пути превращения в короткоживущие токены, разрешающие клиентам доступ к веб-ресурсу.

В IETF и вокруг сейчас происходит небольшой технический скандал, непосредственно связанный с внедрением рекомендаций по использванию негибридных криптосистем ML-KEM в TLS.

Если очень кратко, то переход на постквантовую криптосистему ML-KEM, как единственный механизм получения сеансового секрета, может восприниматься как попытка протолкнуть в TLS некий бэкдор, который отсутствует в X25519 (сейчас X25519 используется вместе с ML-KEM, в составе гибридной криптосистемы, поэтому бэкдор в ML-KEM, для гибрида, только лишь снизит стойкость в два раза).

На днях появилась весьма занятная публикация, непосредственно касающаяся технической части этого скандала: ML-KEM Mythbusting (“Разрушение мифов об ML-KEM”, англ.). Самый удивительный аспект этой публикации в том, что автор прямо утверждает: “в ML-KEM нет бэкдора, это можно доказать”. Вообще, доказать отсутствие бэкдора в криптосистеме не просто сложно, а, часто, невозможно. Особенно, если речь идёт об асимметричных схемах инкапсуляции ключа. Видимо поэтому в публикации по ссылке утверждение заметно более размытое: делается попытка доказать, что это в параметрах ML-KEM недостаточно энтропии для того, чтобы встроить качественный бекдор. (“Качественный” тут – это доступный только держателю секретного ключа от бэкдора, как в DUAL EC DRBG.)

Что имеется в виду? Вот что: якобы, если множество вариантов параметров криптосистемы достаточно маленькое, чтобы перебрать его за обозримое время, то бэкдор там негде прятать – его можно будет обнаружить простым перебором. И вот в ML-KEM, как бы, это множество – всего 34 бита. Как бы, утверждение верное, вот только оно сильно слабее, чем предположение о бэкдоре: бэкдор может находиться непосредственно в алгоритмах, поэтому, для его обнаружения прямым перебором, нужно будет мощность множества параметров возвести в некоторую большую степень (это, примерно, как идея моделирования квантовых вычислений, когда у вас все 2^34 варианта участвуют в расчётах на каждом шаге).

Также упомянут заложенный в алгоритм отказ с ошибкой при обработке корректного шифротекста. Малая расчётная вероятность такой ошибки, – которая вероятность, кстати, прямо связана с выбором параметров, но про это ничего в публикации не сказано, – сравнивается с возможностью аппаратного сбоя: вероятность сбоя, – например, перещёлкивания битов под воздействием космического излучения, – оказывается выше, чем расчётная вероятность штатного сбоя ML-KEM. Но, всё же, аппаратный сбой в результате “пролёта нейтрона”, это совсем не то же самое, что и идеальная ошибка, заложенная прямо в алгоритм. Я, кстати, писал об этом моменте, именно в части ML-KEM.

Вообще, конечно, история, в которой ML-KEM почему-то начинают тщательно “обелять”, доказывая, что там нет бэкдора – несколько подозрительная.

Снова попалось утверждение, что “биометрию”, в отличие от физического пропуска, “нельзя потерять или передать другому человеку”. Вообще-то, основная особенность всякой “биометрии” совсем в другом. Она в том, что биометрические показатели очень сложно, практически невозможно поменять. А вот потерять или “передать другому человеку” – это как раз запросто.

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

Хуже того, возможность потери – прямо касается всех мыслимых биометрических показателей на практике ещё и потому, что реально обрабатывается не биологическая составляющая биометрического показателя, а некоторое его компьютерное представление. Это представление запросто может “поломаться”, причём, с двух сторон – со стороны “носителя” (например, носитель упал с велосипеда: рука теперь – в гипсе; голова – в повязке); и со стороны системы, обрабатывающей представление – датчик не исправен, или его поменяли на другой. И, в отличие от “пропуска”, – а тем более – пароля, – поменять параметры уже нельзя. Ситуация может реально оказаться патовой.

IACR – это Международная ассоциация криптологических исследований (International Association for Cryptologic Research). Результаты очередных выборов руководства и секретариата этой организации не могут расшифровать, потому что одним из доверенных лиц потерян ключ. Для расшифрования результатов голосования нужны ключи трёх доверенных лиц, однако есть ключи только двух, третий ключ – утрачен “в результате человеческой ошибки”, поэтому подсчитать результаты голосования не представляется возможным.

Это, вообще говоря, правильно: было бы странно, если бы или ключ как-то можно было восстановить, или, – что ещё хуже, – подсчитать результаты без одного из необходимых ключей. (То есть, тут примерно тот же случай, как то, что основным, необходимым признаком действительно безопасного “мессенджера” является невозможность централизованно восстановить доступ при утрате ключа.)

Выборы в IACR планируют провести заново. Только смущает один забавный момент: голосование проводится в некой системе “электронного голосования” Helios. Но если зайти на сайт этой системы и попытаться найти там раздел технической документации, то можно обнаружить, что ссылка на эту документацию – не открывается: в DNS просто отсутствует адресная запись для домена, который заявлен в качестве адреса для документации. Так-то вот.

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

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

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

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

Cloudflare опубликовали разбор ситуации, приведшей 18 ноября к глобальному падению сервисов. Оказалось, это не маршрутизация, как я предположил в прошлой записке, а просто – “слишком большой конфигурационный файл”.

То есть, система, которая используется для фильтрации HTTP-запросов, получила слишком большое обновление файла со списком признаков запросов ботов. Слишком большое обновление, как пишут, автоматически сформировалось из-за нескольких логических ошибок. Ошибки были и в коде, извлекающем набор значений из БД, и в коде, который обрабатывал получившийся файл. В общем, всё как обычно – меры борьбы с ботами привели к обрушению сервиса без участия каких бы то ни было ботов.

В качестве ответа на весьма разумные предупреждения о том, что “умные колонки” могут подслушивать окружающих, СМИ цитируют сообщение пресс-службы “Яндекса”, в котором по этому поводу говорится, что, мол, колонки подслушивать не могут, потому что, буквально, “процесс обработки голоса запускается только в тот момент, когда микрофоны улавливают активационное слово”. Это очень забавно.

То есть, чтобы начать “обработку голоса” – их колонке нужно “уловить активационное слово“. Но ведь очевидно, что для улавливания слова – необходимо обработать голос.

Кстати, я недавно писал про то, что “кнопка отключения микрофона”, – в подобном-то устройстве, – так себе аргумент.

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

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

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