Post-quantum TLS: почему JA4 больше не спасает

Ещё год назад схема была понятной: берёшь клиент, который умеет подделывать TLS-рукопожатие, подбираешь профиль под свежий Chrome, получаешь совпадающий JA4 — и антибот пропускает. В 2026 году этот рецепт начал давать сбои по причине, которая к «обходу защит» отношения не имеет вовсе. Браузеры массово перешли на постквантовый обмен ключами, а большинство скрапинг-стеков — нет. И теперь отсутствие постквантового key share само по себе является меткой автоматизации.

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

Что произошло: постквантовый обмен стал нормой, а не экзотикой

Гибридный постквантовый обмен ключами — это связка классической эллиптической кривой X25519 и решёточного механизма ML-KEM (стандарт NIST FIPS 203). Сессия остаётся защищённой, если стойким окажется хотя бы один из двух компонентов. Смысл — защита от сценария «перехвати сейчас, расшифруй потом», когда трафик пишут в архив в расчёте на будущий квантовый компьютер.

Хронология внедрения в клиентах:

Chrome 124 (апрель 2024) — гибридный постквантовый обмен включён по умолчанию; в патчах curl-impersonate это зафиксировано как «кривые X25519Kyber768/X25519MLKEM, введённые в Chrome 124 и 130».
Firefox 132 (ноябрь 2024) — поддержка включена.
Safari на iOS и macOS — постквантовый обмен приехал в октябре 2025.
OpenSSL 3.5.0 (апрель 2025) — гибридные группы X25519MLKEM768, SecP256r1MLKEM768 и SecP384r1MLKEM1024 попали в дефолтный список групп TLS.
Go 1.24 (февраль 2025) — X25519MLKEM768 включён в crypto/tls по умолчанию, если Config.CurvePreferences не задан явно.

Со стороны инфраструктуры картина ещё нагляднее. Cloudflare Radar в апреле 2026 показывал около 67% человеческого HTTPS-трафика с постквантовым шифрованием — против 32% в январе 2025. Akamai сделал постквантовый обмен ключей дефолтом для всех клиентских соединений 31 января 2026 года, завершив раскатку по сети в марте. По отраслевым замерам, около 57,4% всех браузерных транзакций уже постквантово-готовы, причём среди Chrome доля способных к PQ — порядка 93%.

Обратите внимание на асимметрию: поддержка на стороне origin-серверов растёт куда медленнее (у Cloudflare — около 9%). То есть постквантовость сегодня — это в первую очередь характеристика клиента. Ровно то, что интересно антиботу.

Критерий 1: размер key share и структура ClientHello

Постквантовый key share — это не «ещё один флажок в расширении». Он физически большой: около 1124 байт против 36 байт у классического X25519. Последствия видны невооружённым глазом на уровне пакетов.

ClientHello с постквантовым key share выходит за 1400 байт и перестаёт помещаться в один TCP-сегмент. Он разбивается на два и более пакета. А дальше начинается самое интересное для детекта: паттерн фрагментации у разных реализаций разный. Как именно стек режет большой ClientHello, в каком порядке отправляет сегменты, с какими таймингами — это наблюдаемое поведение, которое не выводится из хеша JA4 и которое почти никто из авторов скрапинг-инструментов не воспроизводит осознанно.

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

Критерий 2: согласованность с заявленной версией браузера

Главная ловушка 2026 года — рассинхрон между тем, кем вы представляетесь, и тем, что реально делает ваш TLS-стек.

Антибот-платформы держат базы эталонных ClientHello. Запрос, который в User-Agent и в JA4 заявляет Chrome 131, но приходит без постквантового key share, не совпадает ни с одним известным валидным Chrome 131. Это не «подозрительно» — это логически невозможная комбинация. Настоящий Chrome такой версии физически не может отправить классический key share при дефолтных настройках.

Насколько хорошо это разделяется машинным обучением — тоже посчитано. Классификатор CatBoost на признаках JA4 в исследованиях показывает AUC 0,998 и точность 0,9863; отдельно постквантовый трафик отличается от классического с точностью около 98%. Это не «эвристика с ложными срабатываниями», это практически детерминированный признак.

Критерий 3: готовность конкретных стеков

Здесь и проходит настоящая линия разделения. Разложим по группам.

Отправляют PQ key share по умолчанию

Chrome 124+, Firefox 132+, Safari (iOS/macOS с октября 2025) — эталон, с которым вас сравнивают.
Go 1.24+ — crypto/tls включает X25519MLKEM768 сам, если вы не переопределили CurvePreferences. Важный нюанс: постквантовость есть, но JA4 у голого Go-клиента всё равно не браузерный. Вы получаете «PQ-совместимый, но не похожий на Chrome» отпечаток.
Node.js 24 — везёт собственный OpenSSL 3.5, так что дефолтный список групп уже включает гибрид. Плюс в node:crypto появились ML-KEM через crypto.encapsulate()/decapsulate() и ML-DSA в sign()/verify().

Зависят от того, к чему слинкованы

Python: requests, aiohttp, httpx — используют модуль ssl, а тот берёт системный OpenSSL. На Ubuntu 24.04 в системе живёт OpenSSL 3.0.x, где постквантовых групп нет вообще. Чтобы получить PQ, нужно собирать OpenSSL 3.5 из исходников, подкладывать через LD_LIBRARY_PATH и, скорее всего, пересобирать сам Python. На практике это значит: типовой Python-скрапер в 2026 году отправляет классический key share и на Akamai выглядит аномалией.

Умеют, но только если выбрать правильный профиль

curl_cffi / curl-impersonate — поддержка постквантовых кривых в форке есть и заявлена явно. Но список таргетов тянется от chrome99 до chrome146 (в форке — до chrome150), и старые профили воспроизводят рукопожатие своего времени, то есть без PQ. Копипаста impersonate="chrome116" из гайда двухлетней давности — прямой путь в детект.
uTLS — тот же принцип: профили HelloChrome ниже 131-го не содержат PQ key share. Плюс в библиотеке за 2026 год закрыли две отпечаточные уязвимости: CVE-2026-26995 (версии 1.6.0–1.8.1) и CVE-2026-27017 (1.6.0–1.8.0, рассинхрон выбора шифра для GREASE ECH — Chrome выбирает его детерминированно, а parrot в uTLS кидал монетку между AES и ChaCha20, что для настоящего Chrome невозможно). Обновляться нужно минимум до 1.8.2.

Общий знаменатель: инструменты в основном догнали. Проблема не в них, а в том, что конфиги стареют быстрее, чем браузеры. Профиль, который был идеальным в 2024-м, сегодня работает как маркер.

Как проверить свой стек за пять минут

Отправьте запрос своим боевым клиентом на https://tls.peet.ws/api/all или ja4db.com — они возвращают живые JA3/JA4 и разбор ClientHello в JSON.
Найдите в разборе список supported_groups и key_share. Ищите X25519MLKEM768 (или X25519Kyber768 у старых профилей). Если там только x25519/secp256r1 — постквантового обмена нет.
Сверьте это с версией браузера, которой вы представляетесь. Заявляете Chrome 131+ и не видите PQ-группы — комбинация невалидна, чините профиль.
Посмотрите на размер ClientHello. Меньше ~1400 байт при заявленном свежем Chrome — тот же признак, только с другой стороны.
Прогоните проверку с каждого выходного узла, а не только с рабочей машины: SSL-инспекция на корпоративном шлюзе или у провайдера может переписать рукопожатие за вас.

Что здесь делают прокси

Важно не смешивать два независимых слоя. Постквантовый key share — это про рукопожатие, репутация адреса — про сеть. Антибот считает их отдельно и складывает.

Отсюда два практических следствия. Первое: идеальный резидентный IP не спасёт запрос, который на уровне TLS выдаёт себя за Chrome 131 без PQ-группы — вы проиграете ещё до того, как сервер посмотрит на адрес. Второе, зеркальное: правильно собранное постквантовое рукопожатие не поможет, если сотня ваших сессий приходит с одной датацентровой подсети с испорченной репутацией. Чинить нужно оба слоя, и чинятся они разными инструментами.

Практическая раскладка по задачам: для целей за Akamai и Cloudflare, где считают и рукопожатие, и сеть, разумно брать резидентные прокси и параллельно поднять таргет impersonate до свежего Chrome. Для мобильных приложений и площадок, где вес IP-репутации выше, чем требования к TLS, чаще выигрывают мобильные прокси. А для собственных API, партнёрских выгрузок и внутреннего мониторинга, где антибота нет, переплачивать за резиденшл смысла нет — хватит датацентровых.

Если вы разбираетесь с отпечатком с нуля, начните с базы: как устроен JA4 и что он включает. А когда речь идёт не про HTTP-клиент, а про полноценный браузер, сравнение стелс-сборок и их слабых мест собрано отдельно — nodriver, Camoufox и Patchright в замерах 2026.

Вывод

Постквантовый обмен ключами не задумывался как антибот-механизм. Он стал им побочно: браузеры перешли на него быстро и массово, инфраструктура (Akamai — с 31 января 2026 года) сделала его дефолтом, а скрапинг-стеки разъехались на три группы — уже перешедшие, зависящие от системного OpenSSL и умеющие только при свежем профиле.

Проверка сводится к одному вопросу: отправляет ли ваш клиент X25519MLKEM768 и согласуется ли это с версией браузера, которой вы представляетесь. Если нет — совпадающий JA4 вас не спасёт, потому что сравнивают уже не хеш, а всю форму рукопожатия целиком: размер key share, число TCP-сегментов и порядок их отправки. Хорошая новость в том, что чинится это в большинстве случаев обновлением профиля и версии библиотеки, а не переписыванием скрапера.