Постквантовый обмен ключами добавляет в TLS ClientHello новое поле. Как ML-KEM и ML-DSA меняют отпечатки JA3/JA4 и что это значит для систем обнаружения.
В 2026 году постквантовая криптография перестала быть исключительно предметом исследований и начала появляться в производственных TLS-рукопожатиях. Cloudflare недавно заявила, что классические алгоритмы подписи не могут просто ждать появления лучших постквантовых замен, а APNIC отслеживает, как внедрение PQC выглядит на практике, с операционной точки зрения сетей. Оба материала посвящены развёртыванию, а не фингерпринтингу — но описанный в них механизм меняет тот же самый ClientHello, который всегда читал JA3/JA4-фингерпринтинг. Этот текст — как раз о побочном эффекте: что постквантовый обмен ключами и постквантовые подписи на самом деле делают с вашим TLS-отпечатком.
Ключевые выводы
- Постквантовый обмен ключами добавляет в ClientHello новую поддерживаемую группу, а не новый протокол. Гибридные механизмы вроде
X25519MLKEM768попадают в те же расширенияsupported_groupsиkey_share, которые JA3/JA4 уже хешируют. - Ключевые блоки стали намного больше. Классический key share X25519 занимает 32 байта; гибридный key share ML-KEM-768 занимает заметно больше 1000 байт — иногда этого достаточно, чтобы ClientHello пересёк границу UDP-датаграммы или фрагментированного TCP-сегмента.
- ML-DSA влияет на другое расширение —
signature_algorithms— и отвечает за подписи рукопожатия, а не за обмен ключами: это отдельное, дополняющее изменение в том же сообщении. - Поддержка неравномерна между браузерами и версиями, поэтому сам факт (и позиция) предложения PQC-группы клиентом становится новым, пока весьма высокоэнтропийным сигналом для фингерпринтинга.
- JA4 уже корректно справляется с этим изменением. Поскольку он сортирует расширения и наборы шифров по числовому значению перед хешированием, включение или выключение PQC клиентом лишь меняет набор отсортированных значений, попадающих в хеш, — а не ломает формат, как это сделал бы чувствительный к порядку JA3.
Что именно нового в ClientHello
TLS-фингерпринтинг работает потому, что ClientHello — наборы шифров, расширения, поддерживаемые группы, key share — определяется TLS-библиотекой, а не пользователем. Постквантовый обмен ключами не добавляет новый тип сообщения или дополнительный обмен — он меняет содержимое двух полей, уже присутствующих в том же ClientHello:
supported_groupsполучает одну или несколько новых именованных групп для гибридного обмена ключами, прежде всегоX25519MLKEM768— комбинацию классического Diffie-Hellman на эллиптических кривых (X25519) и решёточного механизма инкапсуляции ключей ML-KEM-768, который NIST стандартизировал как FIPS 203. Черновик IETF по гибридному обмену ключами TLS на основе ML-KEM точно описывает, как это согласуется внутри TLS 1.3.key_shareнесёт непосредственный ключевой материал для тех групп, которые клиент готов отправить заранее. Именно здесь PQC оставляет самый заметный след: один только открытый ключ ML-KEM-768 занимает 1184 байта — на порядок больше, чем 32 байта у X25519, — так что гибридный key share на порядок величины крупнее классического.
Подписи — отдельная история. ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) появляется в расширении signature_algorithms, которое отвечает за аутентификацию самого рукопожатия, а не за то, как выводится общий секрет. Клиент или сервер может поддерживать постквантовый обмен ключами, постквантовые подписи, оба варианта сразу или ни один из них — и каждая комбинация представляет собой отдельный, наблюдаемый паттерн в ClientHello.
Почему гибридный подход, а не чисто постквантовый
Каждая развёрнутая сегодня в TLS постквантовая группа — гибридная: она комбинирует классический алгоритм (X25519) с постквантовым (ML-KEM), а не заменяет X25519 полностью. Общий секрет выводится из обоих компонентов, поэтому атакующему нужно взломать и задачу на эллиптических кривых, и решёточную задачу, чтобы его восстановить, — это хеджирование на случай, если у сравнительно молодого стандарта ML-KEM обнаружится ещё не выявленная слабость. Та же логика хеджирования объясняет, почему в статье Cloudflare именно так рассматривается ML-DSA: постквантовые схемы подписи новее и менее проверены временем, чем схемы обмена ключами, поэтому ожидание гипотетически лучшего варианта — это реальная цена, а не просто осторожность.
Почему это сигнал для фингерпринтинга
Серверу для фингерпринтинга не требуется никакая новая инфраструктура, чтобы заметить PQC — JA3 и JA4 уже хешируют полный список supported_groups и расширений. Меняется то, что теперь кодируют эти хеши:
Датировка версии и сборки. Поддержка PQC внедрялась постепенно — Chrome включил X25519MLKEM768 по умолчанию в определённых диапазонах релизов, другие браузеры следовали по собственному графику. ClientHello, который предлагает (или не предлагает) гибридную группу, в сочетании со всем остальным, что уже читает JA4, сужает идентификацию не только до «это Chrome», но и примерно до какой именно версии Chrome.
Проверка согласованности для поддельных клиентов. Та же логика, которую TLS-фингерпринтинг уже применяет для обнаружения ботов — соответствует ли рукопожатие тому, что должно производить заявленное User-Agent, — получает новое, пока крайне различающее поле. Библиотека для скрейпинга или устаревший инструмент имитации TLS, который ещё не обновили для добавления PQC-группы, будет расходиться с User-Agent, заявляющим актуальную версию браузера, — точно так же, как сегодня рукопожатие Python requests не совпадает с User-Agent Chrome.
Информативным становится не только содержимое, но и сам размер. Поскольку key share ML-KEM намного крупнее классических, сырой размер самого ClientHello становится грубым сигналом — ClientHello с поддержкой PQC заметно больше ещё до того, как кто-либо разбирает отдельные поля.
Нюанс сетевого уровня: более крупные ClientHello
Более крупное расширение key_share означает более крупный ClientHello, а это имеет последствия ниже уровня TLS. Через TCP handshake-сообщения TLS и так могут занимать несколько TCP-сегментов, поэтому более крупный ClientHello по большей части означает лишь чуть больше данных до завершения рукопожатия. Через QUIC, где TLS ClientHello передаётся внутри Initial-пакета, значительно более крупный ClientHello с большей вероятностью потребует от клиента объединения нескольких UDP-датаграмм или опоры на механизм ограничения усиления соединения — граничный случай, который некоторые промежуточные устройства и более старые стеки QUIC исторически обрабатывали не всегда последовательно. В соответствующей стандарту реализации ничего из этого не ломает рукопожатие, но это ещё одно место, где поддержка PQC проявляется как наблюдаемое, зависящее от реализации поведение, а не как невидимое внутреннее изменение.
Что это значит для систем обнаружения
Ничего из этого не создаёт новую категорию обнаружения — это лишь новый набор значений внутри уже существующих категорий. Система обнаружения ботов или борьбы с мошенничеством, которая проверяет согласованность TLS-отпечатков, получает ещё одну ось для анализа: соответствует ли постквантовая «поза» этого клиента тому, что должны производить заявленные браузер и версия, и остаётся ли эта поза согласованной между запросами в рамках одной сессии? VPN или перехватывающий прокси, который завершает и заново устанавливает собственное TLS-соединение, будет нести поддержку PQC своей собственной TLS-библиотеки (или её отсутствие) независимо от исходного клиента — тот же признак, который уже сегодня выдаёт TLS-терминирующие прокси, просто с ещё одним полем для сравнения.
В более широкой картине фингерпринтинга браузера это сигнал сетевого уровня, а не сигнал, наблюдаемый через JavaScript, — вы не можете прочитать TLS ClientHello страницы из свойств navigator. Он встаёт в один ряд с TLS-фингерпринтингом и фингерпринтингом HTTP/3/QUIC как ещё один элемент того, что видит сервер ещё до того, как ваш браузер что-либо отрисует.
Часто задаваемые вопросы
Замедляет ли постквантовый TLS моё соединение?
Незначительно, и в основном на этапе рукопожатия, а не в пропускной способности в дальнейшем. Более крупные key share добавляют небольшой объём одноразовой полосы пропускания и вычислений при рукопожатии; для большинства соединений в современных сетях это практически незаметно. Более значимым это становится в сильно ограниченных сетях или на путях, чувствительных к фрагментации ClientHello, как отмечено выше.
Могу ли я отключить постквантовый обмен ключами, чтобы снизить энтропию отпечатка?
Можете, если ваш браузер предоставляет такую опцию, но это, скорее всего, сделает вас более узнаваемым, а не менее. По мере того как PQC-совместимые группы становятся стандартом в текущих релизах браузеров, ClientHello, заметно лишённый их, выглядит как устаревшая сборка или намеренно изменённый клиент — то есть один сигнал для фингерпринтинга меняется на более подозрительный.
ML-KEM — это то же самое, что ML-DSA?
Нет. ML-KEM (FIPS 203) — это механизм инкапсуляции ключей, используемый для обмена ключами: он появляется в supported_groups/key_share как часть гибридной группы вроде X25519MLKEM768. ML-DSA (FIPS 204) — это алгоритм подписи, используемый для аутентификации рукопожатия, появляющийся в signature_algorithms. Оба алгоритма постквантовые, основаны на решётках и стандартизированы NIST, но решают разные задачи и появляются в разных полях ClientHello.
Влияет ли это на отпечатки JA3 иначе, чем на JA4?
Да, сильнее, чем большинство изменений протокола. JA3 хеширует шифры и расширения в том порядке, в котором их отправил клиент, поэтому он чувствителен к тому, как именно библиотека располагает новую PQC-группу среди уже существующих. JA4 сортирует оба списка перед хешированием, поэтому устойчив к различиям в порядке и отражает только фактический набор значений — включая наличие PQC-групп, — что делает его более стабильным выбором для отслеживания этого перехода. О том, чем в целом отличаются JA3 и JA4, читайте в статье TLS-фингерпринтинг: как JA3/JA4 идентифицируют ваш клиент.
