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

Сообщают про неожиданную замену кода JS-библиотеки Polyfill.io после смены администратора домена или администратора веб-сервера, раздающего код (насколько можно понять). Библиотека используется в качестве внешнего ресурса на многих сайтах, а в результате изменения кода некоторые браузеры пользователей перенаправляются на сторонние сайты. Это происходит без ведома веб-мастера, понятно, который может ничего и не замечать, поскольку для него перенаправлений нет.

Я, например, в 2019 году (но, конечно, и многим раньше) писал про внешние библиотеки на сайтах буквально следующее:

На первый взгляд может показаться, что библиотека выполняет только те функции, ради которых её использовал веб-разработчик. Но это не так: программный код библиотеки может быть изменён владельцем узла, с которого библиотека загружается (либо третьей стороной на пути до клиента), после чего она сможет реализовать какой угодно набор функций, например, собрать пользовательские данные со страницы, изменить её содержание, сделать просмотр недоступным, перенаправить браузер на произвольный адрес и так далее, и тому подобное. В некоторых современных браузерах существует механизм базовой защиты от подмены исходного кода встраиваемых библиотек под названием Subresource Integrity (SRI), но на практике этот механизм ни на каких сайтах не используется.

[…]

Администратор узла, с которого загружается библиотека, волен как угодно вмешиваться в её код. Реально передаваемый клиентскому браузеру файл может выбираться индивидуально, другими словами, атака, связанная с подменой библиотеки, может быть точно настроена на:

конкретные IP-адреса (т.е. конкретных пользователей);
конкретные типы браузеров;
определённое время;
любую комбинацию этих настроек.

То есть даже если администратор исходного веб-ресурса, test.ru в нашем примере, пытается как-то отследить корректность работы узлов, на которых находятся используемые библиотеки, он не в состоянии этого сделать: для IP-адресов, с которых проводится проверка, всё может работать корректно, при этом для других посетителей сайта картина окажется совсем другой.

(Отмечу, в скобках, что хотя бы SRI сейчас начали иногда использовать, но внедрение SRI – всё равно редкий случай.)

В продолжение предыдущей записки, про имена и TLS на веб-серверах, – хороший практический пример. Веб-сервер Nginx использует, обычно, OpenSSL в качестве библиотеки, реализующей TLS. Из-за особенностей кода и библиотечных вызовов, данный веб-сервер не может применять ограничения по версиям TLS для виртуальных хостов, сконфигурированных по SNI в блоках server. Это буквально происходит потому, что не согласованы области видимости имён и статусы TLS-соединения. Другими словами: для того, чтобы начать сопоставлять описания TLS-конфигураций из блоков server, Nginx должен знать имя хоста, по которому выбирается блок. Данное имя передаётся в ClientHello (SNI). Однако к моменту, когда Nginx это имя получает через соответствующий (обратный) вызов функции, в OpenSSL уже создан контекст с поддерживаемой версией TLS – ведь эта версия и выбирается по ClientHello.

Что это означает? Например, означает, что с именами в TLS нужно тщательно всё проверить. Так, если TLS-клиент (браузер) приходит с указанием поддерживаемой версии TLS 1.3 и такая версия указана для сервера по умолчанию, то отключить эту версию директивами ssl_protocol для прочих виртуальных хостов не выйдет – будет согласовываться TLS 1.3, а если согласовать 1.3 не получится, то возникнет ошибка. При этом сама директива ssl_protocol допускается в блоке server, однако в документации её низкая избирательность и, таким образом, относительная бесполезность, тоже отражены: указывать ssl_protocol нужно только для сервера по умолчанию (default/default_server).

Предположим, что для сервера Nginx указана полезная опция ssl_reject_handshake в блоке виртуального хоста по умолчанию (default_server). Это предотвращает успешные TLS-подключения с неверными именами. Соответственно, если в такой конфигурации попытаться указать для прочих виртуальных хостов какие-то иные наборы допустимых версий TLS в ssl_protocol, то применяться они не будут: сервер всегда раньше упрётся в default_server, хоть для этого варианта и прямо указана отмена TLS-хендшейка, не указано никаких уникальных имён хостов и, предположим, даже, – как обычно, – не указана директива ssl_protocol, которая будет инициализирована значениями по умолчанию. Это, конечно, выглядит не слишком логично, но происходит потому, что данный веб-сервер и не пытается обрабатывать имена из контекста TLS-сессии, “выгружая” задачу в сторону TLS-библиотеки (OpenSSL – см. выше).

Вернёмся к конкретной версии TLS – к 1.3. Если при наличии default_server с ssl_reject_handshake в конфигурации присутствуют виртуальные хосты, для которых поддержка 1.3 невозможна (например, с ГОСТ-TLS без совместимых шифронаборов), то, даже если в блоке server для этих имён прямо указаны только версии ниже 1.3, всё равно возникнет довольно занимательная проблема: некоторые клиенты-браузеры смогут подключаться к серверу по проблемному имени хоста, а некоторые – нет. Потому что с клиентом, который заявляет в ClientHello поддержку 1.3, сервер всё равно будет пытаться установить соединение 1.3 и, определив недоступность этой версии, возвратит ошибку (Alert в терминах TLS). А с клиентом, который 1.3 не заявляет, соединение будет успешно и без всяких проблем устанавливаться по версии 1.2 (например). Всё по причине игнорирования блока ssl_protocol веб-сервером. Решением является отключение 1.3 для сервера по умолчанию, то есть – для всех имён хостов сразу.

В TLS для веба важны имена. Например, при подключении по TLS для HTTPS серверу нужно отправить клиенту TLS-сертификат сервера. Если серверных сертификатов несколько, то сервер должен как-то выбрать подходящий по имени. Тут речь не про промежуточные сертификаты, которые добавляются в набор (bundle), а именно про оконечные сертификаты. Если TLS-cертификат не соответствует имени, которое ожидает клиент-браузер, то сессия не будет корректной на стороне клиента. Данный момент, вместе с желанием держать много виртуальных хостов на одном IP-адресе и под одним веб-сервером, является постоянным источником ошибок администрирования.

Посмотрим, что вообще происходит в ходе обработки HTTPS-сеанса и как сервер может определить соответствие имён. В начале TLS-сессии клиент (браузер) обычно передаёт имя сервера в специальном блоке данных – SNI (Server Name Indication). Сервер видит это имя и может использовать его для поиска нужного сертификата и нужного виртуального хоста. Однако клиент определяет имя из своих собственных соображений.

Типовой вариант: в контекст TLS-сессии имя узла SNI приходит из запроса пользователя через DNS. Почему “через DNS”? Потому что браузер должен был найти IP-адрес, к которому он подключается по TCP. При прочих равных, браузер получил IP-адрес из DNS по имени хоста из URL, заданного пользователем. Это действительно важный момент, который, почему-то, инженеры DevOps регулярно выкидывают из области рассмотрения, посчитав “элементарным”. Однако, во-первых, если пользователь ввёл имя, которое не удалось “разрезолвить” в IP-адрес, то и штатного TLS-соединения не случится, хоть бы такое имя и было указано в сертификате (такое вполне возможно). Это, предположим, “элементарная часть”, которая, тем не менее, никак не отменяет возможности указания в SNI имени без DNS-адреса, то есть, без A-, AAAA-записей. Во-вторых, кто угодно может настроить какое угодно допустимое DNS-имя так, чтобы оно показывало на заданный IP-адрес сервера, а потом отправить ссылки с этими именем хоста ничего не подозревающим пользователям. В этом случае, пользователь, штатно набрав это самое “какое угодно” имя хоста, успешно направит браузер на заданный сервер, но браузер обратится туда с “неожиданным” именем в SNI. Если это имя вдруг совпадёт с указанным в предоставленном по умолчанию валидном TLS-сертификате с успешным подтверждением, то браузер даже не выдаст предупреждения, а в сертификате может быть очень много разных имён. (Но, во многих случаях, можно смело считать валидный серверный TLS-сертификат с верным именем достаточной мерой защиты от “ложных” хостов для HTTPS. Особенно, если веб-сервер основного имени хоста доступен по выделенному IP-адресу.)

Основной вывод предыдущего абзаца такой: сервер ориентируется на SNI, но нельзя считать, что SNI, присланное клиентом, как-то привязано к серверным настройкам, соответствует DNS, “защищено сертификатом” и вообще укладывается в формат и ожидания, отражённые в конфигурационном файле веб-сервера. И SNI вообще может отсутствовать. (Кроме того, тут не рассматривается случай, когда данные SNI скрываются от третьей стороны – метод ECH и пр.) На стороне веб-сервера бывает возможность отклонить TLS-соединение, использующее “неожиданное” имя хоста.

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

Как ни странно, но продолжает развиваться тестовый сервер TLS 1.3 – добавил поддержку ещё пары гибридных криптосистем с постквантовой стойкостью: P256Kyber768 и P384Kyber768. До этого сервер поддерживал только X25519Kyber768, которая есть в Chrome/Chromium (и на веб-серверах Google, например). Два новых варианта – совсем редкие.

Удивительно, но P384Kyber768, тем не менее, заявлена в свежих версиях браузера Microsoft Edge под Windows, где включение данной криптосистемы спрятано за флаг (chrome://flags). Да, Edge построен на базе Chrome/Chromium, однако в TLS-стеке там есть дополнительная постквантовая криптосистема. При этом, у P384Kyber768 пока нет индекса в реестре IANA, а у ещё более редкой, в плане поддержки, P256Kyber768 (то же самое, но кривая P-256) – индекс (0x639A) уже имеется.

Вообще, гибридные P256Kyber768 и P384Kyber768 устроены аналогично X25519Kyber768: тут часть Kyber768 вообще совпадает, а в качестве присоединяемого протокола Диффи-Хеллмана (DH) выступают, вместо X25519, ECDH/P-256 и ECDH/P-384.

На сервере я попутно исправил старую ошибку с обработкой точек кривой P-521, из-за которой поддержка DH на этой кривой была давно выключена (это не связано с постквантовыми криптосистемами). Теперь она снова включена – такую версию ECDH использует Firefox.

Изменена обработка TLS-записей, составляющих ответ. Теперь веб-страница с сервера, в большинстве случаев, приходит в нескольких TLS-записях. Это довольно занятный момент: из-за использования постквантовых криптосистем, HTML-ответ, в котором перечисляются ключи и сообщения, теперь может быть довольно большим. Представьте, что клиент приходит с заявленной поддержкой X25519Kyber768 и P384Kyber768, при этом сразу присылает ключи в X25519Kyber768 (1216 байтов). Однако сервер предлагает перейти к P384Kyber768, отправляя HelloRetryRequest, после чего клиент присылает уже ключи P384Kyber768 (ещё 1249 байтов). Всё это должно отразиться в результатах на странице. Чтобы, так сказать, выровнять результаты с постквантовыми криптосистемами и без них – я уменьшил максимальную используемую длину TLS-записи.

Сомневаюсь, что можно найти типовой популярный браузер с большим разнообразием поддерживаемых постквантовых “гибридов”, но вот рабочую сборку curl в контейнере – найти нетрудно (там же, кстати, есть и пара специальных сборок браузеров).

Google уже некоторое время назад для многих пользователей заменил поисковую выдачу на результаты некоторой системы ИИ (LLM), которая генерирует ответы на запрос, “синонимизируя” собранные в интернетах тексты. Не слишком довольные нововведением пользователи извлекли из новой системы массу неверных, абсурдных ответов. И из Google опубликовали разъяснение, что пользователи не совсем правы. В этом разъяснении, на примере запроса “How many rocks should I eat?” (“Сколько камней мне следует есть?”), объясняют, что причина абсурдных, неверных ответов в том, что, во-первых, это редкий запрос (!), во-вторых – для такого запроса в вебе опубликовано мало релевантных данных (да):

Prior to these screenshots going viral, practically no one asked Google that question. […]

There isn’t much web content that seriously contemplates that question, either. This is what is often called a “data void” or “information gap,” where there’s a limited amount of high quality content about a topic.

(До того, как эти скриншоты [т.е., с ответом ИИ про рекомендуемое к ежедневному поеданию количество камней] стали “вирусными”, практически никто не задавал Google такой вопрос. Кроме того, в вебе не много контента, который серьёзно рассматривает такой вопрос. Это то, что часто называют “лакуной в данных” или “информационным пробелом”, когда имеется ограниченное количество тематического контента высокого качества.)

Казалось бы, “интеллект” – он на то и “интеллект”, – тем более, в сервисе поиска информации, – что должен выдать ответ о наличии тут той самой лакуны (“data void” – называть можно так, или иначе, но смысл один), предупредить, что данные в вебе не позволяют судить о данном вопросе “со всей серьёзностью”. Но нет: ИИ LLM – не для этого.

Docker Hub заблокировал доступ с российских IP-адресов. Последовало множество насмешливых инструкций в стиле “простейшего перехода на зеркала и прокси”. Проблема тут, впрочем, привычная: в практике Docker, в сопутствующих скриптовых обвязках (всякий CI/CD), и так не всё хорошо с аутентификацией источников сборок и самих “контейнеров”. Методы, типа DCT (Docker Content Trust), конечно, есть, это известно. Вопрос в их эффективности и использовании на практике. А прокси и “разбегание” зеркал – тут только добавляют ненадёжных слоёв. Кстати, целевые манипуляции часто удобнее проводить именно с точками выхода прокси и точками входа зеркал (вспомните, как работает разное перемешивание и, скажем, onion routing – тут ситуация обратная).

(Update, 09/06/24: доступ вернули через несколько дней.)

Кстати, интересуются примером того, как, более или менее конкретно, может что-то сломать сообщение TLS ClientHello от браузера, если в этом сообщении добавлены параметры Kyber768.

Вообще, нетрудно представить следующую ситуацию. Предположим, есть некоторый диспетчер соединений, работающий в паре с пакетным фильтром. Этот фильтр анализирует пакет данных (то есть, последовательность байтов, имеющую конкретную длину) по заданным правилам на уровне значений байтов внутри пакета и расстояний между байтами с заданными значениями. Например, определяет, что пакет представляет собой начало TLS-соединения с некоторыми свойствами и – перенаправляет этот пакет, как и всю сессию, на какой-то заданный входной узел. Этот узел – уже может быть элементом балансировщика трафика, или входить в состав какого-то механизма DPI, предназначенного для борьбы с возможными атаками, или играть какую-то ещё роль. Базовые правила для фильтра позволяют узнавать заявленные версии TLS (это значения полей в сообщении), определять предлагаемые клиентом криптосистемы – всё по значениям байтов на определённых позициях. Скажем, таким способом можно детектировать начало TLS-сеанса с поддержкой ГОСТ-TLS, со стороны клиента, чтобы на стороне сервиса перенаправить соответствующие сессии на сервер, настроенный конкретно для ГОСТ.

Реализация фильтра не только не проводит разбора сессии, но даже не анализирует пакет с ClientHello как содержащий TLS-сообщение ClientHello – фильтр работает только с байтами и их примитивными индексами. Более того, так как фильтр пакетный, то правила индексирования в нём написаны от значения длины пакета, которое взято из каких-то “максимально обобщённых” соображений. Эти соображения, определяющие длину, не учитывают формата ClientHello и возможного увеличения размеров этого сообщения сразу на несколько сотен байтов. В результате – ожидаемые индексы сдвигаются за допустимые границы, даже в следующий пакет, фильтр перестаёт срабатывать так, как срабатывал раньше, но начинает новые сообщения от браузера Chrome считать дефектными, сбрасывая соответствующее TCP-соединение.

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

То есть, для определения IP-адреса test.ru в глобальной DNS производится поиск “документа” по ключу “test.ru” с извлечением из этого “документа” A-записи, в которой содержится IPv4-адрес. A-записи – это малая часть. В DNS хранятся данные многих типов, например: AAAA – адреса IPv6, MX – имена почтовых серверов, SSHFP – отпечатки хост-ключей SSH и др. При этом, хоть A-записи и очень важны для работы самой DNS, они не являются основными. Основные записи, в смысле иерархии, это SOA-записи (определение основных параметров доменной зоны) и NS-записи (определение списка серверов имён).

DNS позволяет выполнять обратное преобразование – IP-адрес в символьное имя. Но для этого всё равно используется схема “ключ-значение”, где в качестве ключа выступает DNS-имя так называемой обратной зоны, которое формируется из октетов (байтовых элементов) IP-адреса. Это имя располагается в технической зоне .ARPA. То есть, никакого “обратного” поиска “ключа” по “значению” – в DNS нет, но есть прямой поиск записей в специально сконструированных обратных зонах по значению имени, взятому в качестве ключа. Пример обратной зоны: 1.1.1.1.in-addr.arpa – соответствует IPv4-адресу 1.1.1.1 (сервис Cloudflare one.one.one.one).

Если обратную зону в DNS не внести, то и определить через DNS соответствие IP-адреса символьному имени только по IP-адресу и штатным способом – не выйдет. (Но, конечно, можно просканировать все доступные доменные зоны по всем доступным ключам (именам) на предмет A-записей и, таким образом, найти имена, соответствующие данному IP в прямой записи; этих имён может быть очень много.)

Поиск записей в DNS производят программы-резолверы, которые опрашивают DNS-серверы в соответствии с иерархией ключей (DNS-имён): так, tls.dxdt.ru – это имя третьего уровня, находящееся внутри dxdt.ru, а dxdt.ru – второго уровня внутри .ru, а ru – первого уровня внутри корневого домена, имя которого состоит из пустой строки и, при использовании полной записи, тоже отделяется точкой справа, вот так: tls.dxdt.ru. – здесь корневой домен идёт после крайней правой точки. Совокупность программ и протоколов, используемых для поиска в DNS, тоже нередко обозначается буквами D, N и S, но здесь S – это сервис (service), то есть, речь уже идёт про сервис доменных имён.

Основой работы DNS как сервиса является кэширование данных на разных уровнях, в основном, кэширование обеспечивают программы-резолверы. Кэширование решает две основных задачи: это исключение излишней нагрузки и сохранение доступности при кратковременных отказах. Для обеспечения работы сервиса, записям, публикуемым в DNS, сопоставляются различные технические параметры, самый важный из них – это TTL (Time To Live), значение которого позволяет определять динамические параметры кэширования.

При штатной работе, DNS действует именно как база данных: из неё извлекаются далеко не только IP-адреса узлов, про которые так часто пишут, но и списки имён серверов, значения ключей и подписей DNSSEC, значения TXT-записей. Так как DNS является в Интернете всеобъемлющей системой, то и DNS-записи, отличные от A- и AAAA-записей, постоянно используются. Так, TXT-записи, позволяющие опубликовать под заданным именем текстовую строку, повсеместно используются для подтверждения тех или иных прав по управлению доменной зоной, например, при выпуске TLS-сертификатов или при публикации “почтовых” ключей DKIM.

Stack Overflow некоторое время назад запретил использование LLM (ChatGPT и пр.) для генерирования и ответов, и вопросов на сайте. Причины запрета были названы разные, но ситуация стала особенно забавной на днях, когда из OpenAI объявили, что контент Stack Overflow будет официально предоставлен для “обучения” ChatGPT (пока что – несмотря ни на какие протесты некоторых пользователей). То есть, если бы изначального запрета на использование LLM не было, то могла бы возникнуть ситуация, когда в ChatGPT транслируется выдача ChatGPT, что далеко не всегда хорошо (хоть и составляет существенную часть штатной работы данных LLM).

Что касается новостей про атаку TunnelVision, которой соответствует CVE-2024-3661, и про которую сейчас СМИ пишут, что это “уязвимость всех VPN”. Очень (слишком даже) подробное изложение есть по исходной ссылке, однако там начинается весьма издалека, с самых азов. Но для сетевого инженера саму атаку можно детально описать в несколько строчек: к VPN это отношения не имеет, а речь идёт про добавление маршрутов на клиентское устройство средствами DHCP-сервера, маршруты, соответственно, добавляются с привязкой к сетевому интерфейсу на уровне ОС клиента и ведут на перехватывающий узел в той же локальной сети. Дальше работает more-specific, потому что для интерфейса VPN прописано, предположим, 0.0.0.0/0. Понятно, что таким способом можно перенаправить произвольный IP-трафик на промежуточный узел до того, как этот трафик уехал на клиенте в туннельный интерфейс, поднятый приложением VPN. Трафик поэтому будет в открытом виде. Это, собственно, всё.

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

Собственно, авторы исходного сообщения прямо пишут, что вопрос, является ли TunnelVision уязвимостью – спорный, а дальше объясняют, что публикация направлена на противодействие массовым маркетинговым уловкам провайдеров VPN-сервисов, когда заявляется, что какой-то VPN-клиент защищает трафик при подключении к “недоверенной сети”.

Снова пишут про то, что в TLS браузера Chrome длинное ClientHello с ключом Kyber768 ломает обработчики TLS-трафика на каких-то “специальных” веб-серверах и на промежуточных фильтрах. Между тем, чтобы разобраться, как там и что происходит, достаточно посмотреть на конкретное ClientHello, но в некоторых деталях. В качестве примера я взял сообщение от браузера Chrome 124 в том виде, как оно отображается на тестовом сервере TLS. Чтобы просмотр дампа не был скучным, листинг перебивается техническими пояснениями.

Итак, ClientHello TLS 1.3 с постквантовой криптосистемой Kyber768 внутри. CH здесь уже извлечено из TLS-записей и разобранно на элементы: то есть, здесь не учитываются и не упоминаются дополнительные байты, которые расходуются внутри структуры CH на представление полей – идентификаторы, длина записи; обычно – это несколько дополнительных байтов на один элемент структуры. Если бы разбирать и эти байты, то описание излишне усложнилось бы (подробности – можно прочитать в техническом описании TLS).

Version: 0x0303
Cipher suites:
 0xBABA,0x1301,0x1302,0x1303,0xC02B,0xC02F,0xC02C,0xC030
 0xCCA9,0xCCA8,0xC013,0xC014,0x009C,0x009D,0x002F,0x0035

Начальная часть сообщения ClientHello (далее – CH) содержит “исторический” номер версии (здесь указано 0x0303) и перечень шифронаборов. Полезных данных: два байта – номер версии, 32 байта (16*2) – идентификаторы шифронаборов.

 
Client Random: 
85:32:22:08:24:07:B2:98:F3:23:08:4D:A5:FB:E4:59:41:93:13:88:AA:58:53:4E:B4:EF:E7:DA:E8:78:FE:71
Client SessionID: 
C0:39:BC:CE:BB:60:5F:76:D8:75:F9:84:69:E9:9F:C2:AE:7B:8F:D5:9C:E8:01:51:71:9D:21:D2:13:26:DB:5A

Случайное значение от клиента (Client Random). А также клиентский “идентификатор сессии” – в TLS 1.3 этот идентификатор играет роль простого сигнала и ни на какую сессию не указывает.
Здесь всего 64 байта данных, по 32 на каждое поле.

Далее идёт важная часть, которая, собственно, определяет значимые параметры TLS-соединения – набор расширений CH.

Extensions:
 Type: 14906 (0x3A3A); "_undef_ (GREASE)"
 Type: 35 (0x0023); /non-TLS-1.3/
 Type: 23 (0x0017); /non-TLS-1.3/
 Type: 16 (0x0010); "application_layer_protocol_negotiation"
  00:0C:02:68:32:08:68:74:74:70:2F:31:2E:31
 Type: 65281 (0xFF01); /non-TLS-1.3/
  00

Здесь 0x3A3A (тип 14906, первое расширение) – это пример того, что называется GREASE, а именно – специальных, заведомо неподдерживаемых, значений и идентификаторов, которые Chrome дописывает в TLS-сообщения с целью (как заявлено) проверки корректной работы парсеров и прочего программного обеспечения, задействованного в обработке TLS. Такие обработчики, согласно спецификации, должны успешно игнорировать неизвестные расширения и параметры (если контекст позволяет, конечно). Так что, вообще говоря, добавление разных там новых “постквантовых ключей” не является чем-то особенным – всякие фиктивные элементы писались в браузерные сообщения и раньше, именно для того, чтобы обновления не оказывались полной неожиданностью (ниже нам встретятся и другие GREASE). Другие расширения из этого фрагмента, с типами 35 (session_ticket), 23 (extended_master_secret), 16 (ALPN) и 65281 можно не рассматривать: они небольшие по объёму (например, extended_master_secret – это всего лишь сигнал, вообще не содержащий байтов данных), часть из них не поддерживается в TLS 1.3. Поэтому – переходим дальше.

Как говорится, а вот и он – постквантовый элемент. Клиентский открытый ключ Kyber768 содержится уже в следующем расширении – key_share. Оцените огромный размер данных, которые тут приводятся без сокращений.

 Type: 51 (0x0033); "key_share"
  _undef_ (GREASE) (0xAAAA)
   Unsupported group: 0xAAAA (_undef_ (GREASE))
  X25519Kyber768Draft00 (0x6399)
   Hybrid: X25519 + Kyber
   Len (octets, dec.): 1216
   Key share data:
    X25519
     x = 0xF2C744A07B3BC36F6C427620351A009D29BB36E6EF259A177A3881ECEB22100D
    Kyber768 client public key:
     Vpoly_1 (packed):
      6CA39FB332275395989A56958E6B61A7B3B447D6A2C9062837E39695B44E4A5B
      36C9A7B06F4A912ED6ABC2E3BD2FD8584BE42F5822A3A54A4CC14812F3D87A05
      5371F2E1222817A63FAA531CD7691DE59694F9B4ACD3B8CD638A44B9B566C094
      3A95B7DCB186CC840C53A90041FB15FFBB214E3BCE8AB0C3D278897A61992601
      BB88427608A8AEC6385C0C6319A56B8B47CA240F3A134DD6AF4B56A6333158A9
      D391B495A76EA0C5F67C49457042AFFB508766414C88A8EA23B1328723FC9199
      8BA78414527F2DC234C0213CF5DAB976910EA3DC641C8B818FF73F4CEB53C929
      C03F61CFD8A04CE88A3EB16CCAE02C9541438A16D4A7FE8129F7F04C0C0A9E14
      60ACA4049F84C2C4E5DB1B4185CF0FE8C305333CBC7B3970A27E42C23F47F003
      E3815FDE20830B912501E388BEB9B14399ADD2EA174E3C040810917E555084E1
      5B75B9599914523799B6885721D08A46741501EBACA747C905B7AA31E3D3137C
      718B50A908DC111E49161448B102D3F0411EA70D9F91CFF6F50D5D54B9AB7B11
     Vpoly_2 (packed):
      1356BAA03CAD6E2730C334C24D492E6A11088F7B036A7ACBEF26407C1A9DCDFA
      473D677C3447915AE28EB094326093668FC27DCB85086219A1A0E6A6FC367CE0
      9A4396EA75FAFA1CD336311DE505BE5075A36C436B58673CF6387AF45BDBD523
      C082864EB6BD20E6A587C99976FA04C9548FB9731BC5B80D483984D8E84D89A3
      8A0D210D58C22C9DA0316D9214B45B46C7353228C67A62F101DD79267C071CEE
      9C1FA2DA976294AD6031C245397BDFB11A3AF012DF154B6D126439F579F85C38
      77AB844586159ECCAD0D468A3D94A5DABA43B26722B4C24FEFDC19FC62355341
      29B1FBABC7D242DDEB59DB00C564546DBD384653CCB55436BCCA4B7C4BA585E3
      50B078A48B8F02C9BA79154DF463E42538DB7616AC04C9C1284F0E2918009CAE
      49EB18708A2BD322A3A613CCCF43B3CA288780546FEBF03B6FC3394816359406
      5642DC4930B4B36D5B5122A90871006975496515650608E632414B5054019BB5
      CB280DF34DA9087AB2FA2ADB94588AB2A8C8D3CA3DAB7248357001D0C175269C
     Vpoly_3 (packed):
      AAF30D9EA1ADEF802799581653A0A0D4D692EB2B644F6C84059388947838138A
      1D24464054A9A3E9385FD3E4A6C0C56D09D80F984705B2E4B4244A4D67C3CD58
      7739688170695AC9AA4C354A349AB04ACBD4753E6B519468EB900A290C3AD255
      A004307B1572C0072946B73639F897D434086C515F6BBA53BB10B6A3D4B4AC86
      58E4A4C3EE452C3D7442536756D4F7041775897C2240C4B437CC97CC5E4270FD
      986DEE9842831B1F233B543F724A9E5B0446BB22CF6C8AC278CD4E275482F61B
      A3461582291443967ED0AA78723A2EBE448AC24726D8EA8F5264BC45A4A7D8B4
      C04EFC7A7271AA361B454EE43365644E5DA9A5F8A5A838D4C93EB6970716B98D
      5617F4E4829E93A816432C9B7621ECF2CB5A75BDD4446F58BC57F1A36215467F
      1722A31FFA2432574F028848A92A0FC5C48C4F391FDF2214429454A6015DD9E6
      496A3B1D5F9768C5326AB2997E038CA5E7E34347D5C5C8E7AE00A9CB48FA4A43
      54768F3C586430B8C4E8C3CAE13EE0265910A0B01FA037CAE333B13B63601397
     Rho (bytes):
      44D2E20D0D57AA501ED3DE916106FF5DA95E4BE2AD4335034F2C757352305980
  X25519 (0x001D)
   x = 0xFB6C61B9A2E5323674FD2C49FA02DF5E1335F52EFBF984C9FC2401F01B1F7C5E

В TLS 1.3 стороны уже на самом первом этапе вычисляют общие секретные ключи, чтобы перейти на защищённый обмен данными. Для этого свою часть открытых ключей (или открытых значений протокола Диффи-Хеллмана, что здесь эквивалентно) должен прислать клиент. Клиент присылает эти ключи в расширении key_share.

В данном случае браузер Chrome прислал нам значение X25519 (внизу) и гибридный набор из X25519 и Kyber768 – то есть, X25519Kyber768draft0 (идентификатор 0x6399 – в начале). Важно не запутаться: криптосистема с постквантовой стойкостью тут одна, она называется Kyber768 (“на научном языке” это KEM – Key Encapsulation Mechanism). Однако в TLS эта криптосистема внедряется в гибридном варианте, то есть, на прицепе к классической, хорошо отработанной, криптосистеме X25519, которая есть разновидность реализации протокола Диффи-Хеллмана. Данный гибрид всё ещё считается “черновым вариантом” – draft. Поэтому полное название X25519Kyber768draft0.

Если приглядеться, то в этом же расширении есть ещё один, не столь массивный, блок, названный X25519. Это другое, отдельное открытое значение X25519, которое может быть использовано сервером, если сервер не поддерживает X25519Kyber768draft0. К входящему в гибридный вариант значению X25519 свободный вариант отношения не имеет. Это та же криптосистема X25519, в гибриде она работает абсолютно и точно так же, как и без “гибридизации”, но название отличается, как отличаются и значения ключей (обозначены “x”).

Постквантовая часть ключей указана в блоке “Kyber768 client public key”. Ключ Kyber768 состоит из четырёх обособленных значений: это три полинома (Vpoly_N) и параметр Rho. И только лишь ключ Kyber768 занимает уже 1216 байтов. X25519 добавляет лишь 32 байта (в составе гибрида).

Другие элементы расширения key_share, которые тоже отмечены GREASE, это, опять, фиктивные значения, как и в следующем расширении – supported_groups.

 Type: 10 (0x000A); "supported_groups"
  0xAAAA (_undef_ (GREASE))
  0x6399 (X25519Kyber768Draft00)
  0x001D (X25519)
  0x0017 (Secp256r1)
  0x0018 (Secp384r1)

В этом расширении – поддерживаемые клиентом схемы криптосистем. Расширение называется “Поддерживаемые группы” (supported_groups). “Группы” здесь – это технический термин, обозначающий математическую структуру (группу), которая применяется в той или иной криптосистеме (кстати, можно сказать, что “схема”, с математической точки зрения, даже более технический термин, который вполне можно так применить, но, конечно, это лишь случайное совпадение).

Данное расширение всего лишь перечисляет идентификаторы параметров, которые клиент готов использовать. Часть ключей – уже передана в составе key_share. Поэтому тут и присутствуют X25519Kyber768Draft00 и X25519. Однако сервер может не поддерживать ни X25519Kyber768Draft00, ни X25519. В таком случае предстоит выбрать что-то из оставшихся вариантов: Secp256r1 и Secp384r1, под которыми подразумевается протокол Диффи-Хеллмана (DH) на кривых P-256 и P-384. А GREASE – выбрать нельзя. Для перехода к другой криптосистеме сервер, в ответ на CH, отправляет сигнальное сообщение HRR (HelloRetryRequest), указывая в расширениях к нему предпочитаемую криптосистему. Пересогласование криптосистемы для DH поддерживается на тестовом сервере tls13.1d.pw – так что эффект нетрудно увидеть, понажимав Ctrl+F5 (Refresh) в браузере: при пересогласовании клиент пришлёт новое CH, уже с другим составом key_share.

Возникает резонный вопрос: поддержка Kyber768 на серверной стороне не очень-то распространена, нужно ли пересогласование при каждом CH от Chrome с Kyber768? Нет, в типовом случае, серверу не нужно ничего пересогласовывать – сервер может проигнорировать гибридный постквантовый набор и сразу использовать X25519 (поддержка есть практически повсеместно), потому что ключ этой криптосистемы указан в CH от Chrome (не гибридный, а отдельный). Если, конечно, сервер не поддерживает X25519, тогда пересогласовать криптосистему потребуется, но не из-за наличия Kyber768.

Следующее расширение – это фиктивное ECH (Encrypted Client Hello).

 Type: 65037 (0xFE0D); "ECH /DRAFT/"
  Type: 0x00 (Outer)
  HKDF: 0x0001 (HKDF-SHA256)
  AEAD: 0x0001 (AES-128-GCM)
  Config id: 0x04
  Encapsulated key (bytes):
   08FC1E6C6A441874D38689375F9C906827516F2F306BBD8B2376569F99CF0069
  Payload (dummy):
   ECADC2C291D6311FCD925306392EE88CD057D42178C0B60EF5B14814F2CF669E
   05230A0F3D6AABADA0A3EB78D240E22BE2DE5893A50B3AEC4056B77B5CACF7C9
   07F5E6EE853268C23595E22F59E9D190BE9ECCD05B76092CBA00FCCE1C072283
   7CBE371C871817540D8E9429CB10F4CCA3089AB36154D7AE2578FF5D12884F3D
   437AB7A97E0FDA19DCC4B423A4DFD2CF

ECH служит для доступа к скрытым сервисам. Базовое применение: сокрытие имени узла, с которым устанавливается TLS-соединение. Chrome включает фиктивное расширение в CH даже для узлов, которые ECH не объявляли. Это метод придания единообразия TLS-трафику. Расширение ECH устроено довольно сложно, содержит внутри дополнительную структуру и большое по объёму данных поле Payload, которое, в случае фиктивного расширения, имитирует полезные данные ECH (зашифрованное CH). ECH, в данном случае, добавляет ещё 182 байта.

 Type: 00 (0x0000); "server_name"
  00:00:0E:00:00:0B:74:6C:73:31:33:2E:31:64:2E:70:77
  hostname: tls13.1d.pw

Расширение SNI, содержащее имя узла, с которым устанавливается TLS-соединение. Именно данные этого расширения и должно скрывать ECH (в данном случае – ECH не поддерживается). Обычно, это расширение не очень большое по объёму (но зависит от используемого имени).

 Type: 45 (0x002D); "psk_key_exchange_modes"
  01:01
 Type: 17513 (0x4469); /non-TLS-1.3/
  00:03:02:68:32
 Type: 43 (0x002B); "supported_versions"
  0x8A8A (_undef_ (GREASE))
  0x0304 (TLS 1.3)
  0x0303 (TLS 1.2)
 Type: 05 (0x0005); "status_request"
  01:00:00:00:00
 Type: 13 (0x000D); "signature_algorithms"
  00:10:04:03:08:04:04:01:05:03:08:05:05:01:08:06
  06:01
 Type: 11 (0x000B); /non-TLS-1.3/
  01:00
 Type: 27 (0x001B); /non-TLS-1.3/
  02:00:02
 Type: 18 (0x0012); "signed_certificate_timestamp"
 Type: 10794 (0x2A2A); "_undef_ (GREASE)"
  00

Из оставшихся расширений в контексте этой записки интерес представляет только supported_versions (тип 43): в TLS 1.3 именно это расширение содержит настоящий список поддерживаемых клиентом версий TLS. Chrome, помимо очередного GREASE, передаёт здесь идентификаторы версий 1.3 и 1.2. Наличие supported_versions и делает это CH сообщением версии TLS 1.3.

А заканчивается набор расширений всё тем же GREASE.

Итак, на примере конкретного ClientHello хорошо видно, что ключ Kyber768, действительно, занимает основную часть сообщения. Обычный вариант CH, без “постквантовой стойкости”, будет отличаться только отсутствием ключа X25519Kyber768Draft00, всё остальные поля – применяются точно так же.