От JA3 к JA4+: Как современные WAF идентифицируют антидетект-браузеры на сетевом уровне

· 14 мин чтения
ja4 tls-fingerprinting waf anti-detect network-security
От JA3 к JA4+: Как современные WAF идентифицируют антидетект-браузеры на сетевом уровне

Готовы защитить свою цифровую личность?

Выберите тариф и запускайте незаметные профили уже сегодня.

Начать

Каждый раз, когда браузер открывает HTTPS-соединение, пакет TLS Client Hello транслирует отпечаток, который однозначно идентифицирует программное обеспечение, инициирующее запрос. На протяжении многих лет JA3 был стандартом де-факто для захвата этого отпечатка. Но в 2023 году Джон Олтхауз — один из трёх соавторов JA3 (совместно с Джеффом Аткинсоном и Джошем Аткинсом из Salesforce) — опубликовал JA4+, семейство методов фингерпринтинга, которое мгновенно сделало большинство существующих техник обхода антидетект-браузерами устаревшими. Если ваша система мультиаккаунтинга всё ещё полагается на рандомизацию JA3, вас почти наверняка флагуют на сетевом уровне ещё до того, как ваш JavaScript начнёт выполняться.

В этой статье мы разберём техническую эволюцию от JA3 к JA4+, объясним, почему наивные стратегии рандомизации не работают против нового стандарта, и что должен делать правильно спроектированный антидетект-браузер для сохранения невидимости на сетевом уровне.

Как работает фингерпринтинг JA3

JA3 вычисляет MD5-хеш из пяти полей, извлечённых из сообщения TLS Client Hello:

  1. Версия TLS — версия протокола, заявленная клиентом
  2. Наборы шифров (Cipher Suites) — список поддерживаемых алгоритмов шифрования в порядке предпочтения
  3. Расширения (Extensions) — список кодов типов TLS-расширений в порядке следования
  4. Эллиптические кривые (Supported Groups) — объявленные именованные кривые
  5. Форматы точек эллиптических кривых — поддерживаемые типы форматов точек

Эти поля конкатенируются через запятую и хешируются:

JA3 = MD5(TLSVersion,CipherSuites,Extensions,EllipticCurves,ECPointFormats)

Реальная строка JA3 для Chrome 120 может выглядеть так:

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,
0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,29-23-24,0

Результирующий MD5-хеш становится отпечатком JA3. Каждая одинаковая сборка браузера на одной ОС выдаёт один и тот же хеш, что позволяет тривиально отличать Chrome от Firefox или реальный браузер от сессии Python requests.

Почему рандомизация JA3 казалась рабочей

Хеш JA3 зависит от порядка. Перемешивание наборов шифров или расширений полностью меняет хеш. Ранние антидетект-браузеры эксплуатировали это:

  • Рандомизируя порядок наборов шифров для каждой сессии
  • Инжектируя фиктивные расширения (например, GREASE-значения)
  • Варьируя объявленные поддерживаемые группы

Это работало, потому что правила WAF на основе JA3 обычно поддерживали allowlist’ы известных хешей. Рандомизированный хеш не совпадал ни с одним известным браузером, но и ни с одним известным ботом — поэтому часто проходил как «неизвестный», а не «заблокированный».

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

JA4+: Принципиально новый подход

JA4+ — это не единичный отпечаток, а целое семейство методов фингерпринтинга:

ОтпечатокЧто захватывает
JA4TLS Client Hello (замена JA3)
JA4STLS Server Hello (замена JA3S)
JA4HHTTP-отпечаток клиента
JA4LРасстояние / задержка (latency)
JA4XX.509 TLS-сертификат
JA4SSHОтпечаток SSH-трафика
JA4TTCP-отпечаток
JA4TSTCP Server Response

Ядро — отпечаток JA4 — решает слабости JA3 тремя архитектурными решениями, которые делают рандомизацию бессмысленной.

1. Каноническая сортировка устраняет зависимость от порядка

JA4 сортирует наборы шифров и расширения в алфавитном порядке перед хешированием. Два клиента, предлагающих один и тот же набор шифров в разном порядке, производят одинаковый JA4-отпечаток. Одно это изменение инвалидирует самую распространённую технику обхода JA3.

# JA3: порядок важен
Ciphers: 4865,4866,4867,49195 → hash_A
Ciphers: 49195,4867,4866,4865 → hash_B (другой!)

# JA4: каноническая сортировка
Ciphers: 4865,4866,4867,49195 → hash_X
Ciphers: 49195,4867,4866,4865 → hash_X (одинаковый!)

2. Структурированный префикс для быстрой классификации

JA4 предваряет хеш-часть человекочитаемым префиксом:

JA4 = t13d1516h2_8daaf6152771_e5627efa2ab1
       │││  ││││││
       ││└──┘│││││
       ││    ││││└─ ALPN: первый+последний символ
       ││    │││└── Количество расширений (hex)
       ││    ││└─── Количество наборов шифров (hex)
       ││    │└──── Наличие SNI (d=domain, i=IP)
       ││    └───── Версия TLS
       │└────────── Протокол (t=TCP, q=QUIC)
       └─────────── (зарезервировано)

Этот префикс невозможно рандомизировать без изменения реальных возможностей TLS-стека. Нельзя заявить поддержку 22 наборов шифров, перечислив при этом только 15 — счётчик вычисляется из фактического содержимого Client Hello.

3. Исключение GREASE-значений

GREASE (Generate Random Extensions And Sustain Extensibility) — это placeholder-коды расширений и шифров, которые браузеры инжектируют для проверки толерантности серверов. JA4 удаляет все GREASE-значения перед построением отпечатка, поэтому внедрение случайных GREASE-кодов — ещё одна популярная техника обхода JA3 — не даёт никакого эффекта на хеш JA4.

Как WAF используют JA4+ на практике

Современные WAF (Cloudflare, Akamai, F5) развёртывают отпечатки JA4+ в многоуровневой детекции:

Уровень 1: Проверка консистентности протокола

Префикс JA4 раскрывает версию TLS и количество возможностей. Запрос, утверждающий через User-Agent, что он Chrome 124, но представляющий JA4-префикс, характерный для Python-библиотеки urllib3, немедленно подозрителен. WAF даже не нужно вычислять полный хеш.

Уровень 2: Сопоставление с известными браузерами

Каждая версия крупного браузера на каждой крупной ОС производит небольшой набор JA4-отпечатков (обычно 1-3 на комбинацию версия/ОС). WAF поддерживают базы этих отпечатков. Запрос от «Chrome на Windows», чей JA4 не совпадает ни с одним известным отпечатком Chrome-на-Windows, получает повышенный уровень проверки.

Уровень 3: Кросс-сигнальная корреляция (JA4H)

JA4H фингерпринтирует HTTP-уровень: порядок заголовков, паттерны Accept-Language и другие HTTP-сигналы. Соединение может иметь валидный JA4 TLS-отпечаток, но несогласованный JA4H HTTP-отпечаток — что выявляет, что TLS-стек и HTTP-стек относятся к разному ПО.

Уровень 4: Поведение сети (JA4L, JA4T)

JA4T захватывает характеристики TCP (размер окна, TTL, MSS), коррелирующие с ОС. JA4L измеряет задержку round-trip для оценки физического расстояния. «Пользователь в Токио», чья JA4L-задержка соответствует маршрутизации из датацентра US East Coast, будет отмечен.

# Псевдокод: многоуровневая валидация JA4+
def validate_request(request):
    ja4 = extract_ja4(request.tls_client_hello)
    ja4h = extract_ja4h(request.http_headers)
    ja4t = extract_ja4t(request.tcp_metadata)
    
    # Проверка TLS-отпечатка vs заявленный браузер
    claimed_browser = parse_user_agent(request.headers['User-Agent'])
    if ja4 not in KNOWN_FINGERPRINTS[claimed_browser]:
        return ELEVATED_RISK
    
    # Кросс-проверка HTTP-поведения
    if ja4h not in EXPECTED_HTTP_PATTERNS[claimed_browser]:
        return ELEVATED_RISK
    
    # Верификация консистентности ОС через TCP-стек
    claimed_os = parse_sec_ch_ua_platform(request.headers)
    if ja4t.os_family != claimed_os:
        return BLOCK
    
    return PASS

Почему распространённые стратегии обхода не работают против JA4+

Стратегия 1: Рандомизация наборов шифров

Результат: Неэффективна. JA4 сортирует канонически. Один и тот же набор шифров всегда даёт один и тот же хеш, независимо от порядка.

Стратегия 2: Инъекция расширений

Результат: Частично детектируется. Добавление расширений меняет счётчик расширений в JA4-префиксе, который должен совпадать с профилями известных браузеров. Реальный Chrome 124 имеет ровно N расширений — добавление или удаление любого меняет префикс на несовпадающее значение.

Стратегия 3: Реальный браузерный движок с модифицированными заголовками

Результат: Детектируется через кросс-сигнальный анализ. Если вы используете TLS-стек Chromium, но модифицируете HTTP-заголовки, JA4 и JA4H будут несогласованны. TLS-отпечаток говорит «Chrome», а HTTP-отпечаток — «кастомный клиент».

Стратегия 4: Проксирование через TLS-стек реального браузера

Результат: Детектируется через JA4T и JA4L. TCP-отпечаток выдаёт ОС прокси (часто Linux, когда заявляется Windows), а измерения задержки показывают маршрутизацию через датацентр.

Что должен делать правильный антидетект

По-настоящему необнаружимый антидетект-браузер должен обеспечивать консистентность по всем измерениям JA4+ одновременно. Это требует архитектурных решений, выходящих далеко за рамки конфигурации.

Полный контроль над браузерным движком

Антидетект-браузер должен использовать реальный движок (Gecko, Blink), соответствующий заявленной идентичности. Santiago использует модифицированный движок Camoufox (Firefox/Gecko), что означает подлинный TLS-стек Firefox — производящий аутентичные JA4-отпечатки без какой-либо симуляции.

Целостность сетевого стека

TLS-конфигурация не должна инжектироваться через прокси или middleware. Расширения вроде encrypted_client_hello, application_layer_protocol_negotiation и signature_algorithms должны приходить от самого браузерного движка, а не от обёртки, перехватывающей и модифицирующей Client Hello.

Консистентность TCP на уровне ОС

Параметры TCP (размер окна, TTL, MSS, фактор масштабирования окна, поддержка SACK) должны соответствовать заявляемой операционной системе:

# Windows 10/11 — типичный TCP-отпечаток
TTL: 128, Window: 65535, MSS: 1460, WScale: 8, SACK: permitted

# macOS — типичный TCP-отпечаток
TTL: 64, Window: 65535, MSS: 1460, WScale: 6, SACK: permitted

# Linux — типичный TCP-отпечаток
TTL: 64, Window: 29200, MSS: 1460, WScale: 7, SACK: permitted

Корреляция расширений с устройством

Объявленные TLS-расширения должны соответствовать профилю устройства. Например, профиль Chrome на Android не должен объявлять расширение server_name с паттерном, типичным для десктопного Chrome, и должен включать мобильные значения ALPN.

Осведомлённость о QUIC/HTTP3

Современный Chrome использует QUIC для многих соединений. JA4+ включает фингерпринтинг QUIC (префикс q). Антидетект-браузер, который заявляет себя как Chrome, но никогда не инициирует QUIC-соединения — или инициирует QUIC с не-Chrome отпечатком — создаёт детектируемую аномалию. Браузер должен либо корректно реализовать QUIC с правильным отпечатком, либо стабильно отключать его способом, соответствующим реалистичной сетевой конфигурации (например, корпоративный файрвол, блокирующий UDP 443).

База данных JA4+: масштаб проблемы

Проект JA4+ поддерживает открытую базу отпечатков с вкладами от крупных CDN и вендоров безопасности. По состоянию на начало 2026 года эта база содержит:

  • ~1 200 уникальных JA4-отпечатков для основных комбинаций браузер/ОС
  • ~400 отпечатков для распространённых инструментов автоматизации (Playwright, Puppeteer, Selenium)
  • ~800 отпечатков для HTTP-клиентских библиотек (requests, aiohttp, curl и т.д.)

Это означает, что WAF могут позитивно идентифицировать большинство инструментов автоматизации до выполнения какого-либо JavaScript. Отпечаток встроен в самый первый пакет TLS-хендшейка — нет возможности перехватить или модифицировать его постфактум.

Практическое тестирование: проверка своего JA4-отпечатка

Вы можете проверить JA4-отпечаток своего браузера несколькими способами:

Через Wireshark

Wireshark 4.2+ включает нативную диссекцию JA4. Захватите трафик на своём интерфейсе, отфильтруйте пакеты TLS Client Hello и изучите поле ja4:

tls.handshake.type == 1

Через CLI-инструменты ja4+

Официальные инструменты JA4+ могут анализировать PCAP-файлы:

# Захват трафика
tcpdump -i eth0 -w capture.pcap -c 100

# Анализ через ja4
ja4 --pcap capture.pcap --json | jq '.[] | {ja4, ja4h, ja4t}'

Через онлайн-сервисы

Сервисы вроде tls.browserleaks.com и tls.peet.ws отображают ваш JA4-отпечаток в реальном времени, позволяя сравнить его с базами известных браузеров.

Заключение

Переход от JA3 к JA4+ представляет собой парадигмальный сдвиг в сетевом фингерпринтинге браузеров. Стратегии рандомизации, работавшие против JA3, не просто неэффективны против JA4+ — они активно вредят, порождая отпечатки, которые кричат «попытка обхода» любому современному WAF.

Единственный жизнеспособный подход — аутентичность: использование реального браузерного движка с немодифицированным сетевым стеком, обеспечение консистентности на уровнях TLS, HTTP, TCP и приложения. Любой антидетект-браузер, который рассматривает сетевой фингерпринтинг как проблему конфигурации, а не архитектуры, будет обнаружен JA4+ — не иногда, а каждый раз.

Готовы защитить свою цифровую личность?

Выберите тариф и запускайте незаметные профили уже сегодня.

НачатьУзнать больше

Получайте 15% пожизненную комиссию с каждого реферала.

Стать партнёром →

Похожие статьи

Маскировка CDP: Почему Playwright и Puppeteer детектируются за секунды

15мин чтения

Client Hints против User-Agent: Настройка полей Sec-CH-UA для прохождения фильтров Google

13мин чтения

Аудио-контекст и шрифты: Забытые векторы детекции мультиаккаунтов

12мин чтения