TLS-отпечаток JA4: как антифрод отличает curl через прокси от реального Chrome
Содержание
Что вообще такое JA4 и откуда он взялся
JA3 появился в 2017-м, и лет пять антифрод-системы жили с ним припеваючи. Идея простая: собрать байты ClientHello — версию TLS, список шифров, расширения, эллиптические кривые, форматы точек — склеить через запятую и посчитать MD5. Получалась строка вроде `771,4865-4866-4867-49195,0-11-10,29-23-24,0`. Дальше — сравнивай с базой известных клиентов и радуйся.
Проблема вылезла, когда Chrome начал рандомизировать порядок расширений (TLS GREASE — Generate Random Extensions And Sustain Extensibility). Один и тот же Chrome на одной и той же машине выдавал разные JA3 при каждом соединении. Хеш перестал быть стабильным. Антифрод-вендоры схватились за голову, а FoxIO в 2023-м выкатил JA4.
JA4 не просто «JA3 v2». Это переработанная схема, где отпечаток разбит на три части и нормализован так, чтобы GREASE-мусор не ломал хеш. Формат: `a_b_c`.
- `a` — тип соединения (`t` для TCP, `q` для QUIC), версия TLS, наличие SNI, количество шифров, количество расширений, ALPN.
- `b` — отсортированный список шифров + список расширений (без GREASE).
- `c` — сигнатуры эллиптических кривых и форматы точек.
Пример реального JA4 от Chrome 124 на Windows:
```
t13d1516h2_8daaf6152771_b186095e22b6
```
Расшифровка: `t` — TCP, `13` — TLS 1.3, `d` — domain (SNI есть), `15` — 15 шифров, `16` — 16 расширений, `h2` — HTTP/2 в ALPN. Дальше два хеша по 12 hex-символов.
Почему curl через прокси палится мгновенно
Возьмём голый curl 8.5.0 на Ubuntu 22.04:
```bash
curl -v https://example.com 2>&1 | grep -A2 "Client Hello"
```
JA4 получается примерно такой:
```
t13d1516h2_8daaf6152771_b186095e22b6
```
Стоп, он совпадает с Chrome? Нет. Я специально показал похожий, чтобы вы поняли — визуально строки похожи, но хеши в частях `b` и `c` отличаются. Реальный curl даёт что-то вроде:
```
t13d1516h2_8daaf6152771_02713d6af862
```
Разница в третьей части. Chrome использует X25519Kyber768 для пост-квантовой криптографии (с версии 116), curl — нет. Chrome шлёт 16 расширений, curl — 13-14. Chrome добавляет `application_settings` (ALPS) и `encrypted_client_hello`, curl о них не знает.
Вот таблица реальных отпечатков, снятых через Wireshark + плагин JA4 в апреле 2024:
| Клиент | JA4 | Шифров | Расширений | Kyber |
|---|---|---|---|---|
| Chrome 124 Win | t13d1516h2_8daaf6152771_b186095e22b6 | 15 | 16 | да |
| Firefox 125 | t13d1715h2_5b57614c22b0_3d5427e3c8a1 | 17 | 15 | да |
| curl 8.5.0 | t13d1314h2_8daaf6152771_02713d6af862 | 13 | 14 | нет |
| Go 1.22 net/http | t13d1011h2_9dc44e2c1b0a_2c2b1a1e4d3f | 10 | 11 | нет |
| Python requests | t13d1313h2_8daaf6152771_02713d6af862 | 13 | 13 | нет |
Видите? curl и Python requests почти идентичны — оба используют OpenSSL под капотом. И оба моментально вычисляются.
Как антифрод это использует на практике
Cloudflare с 2023-го крутит JA4 в правилах WAF. Не как единственный фактор, а в связке с User-Agent. Логика такая: если User-Agent говорит `Mozilla/5.0 ... Chrome/124.0.0.0`, а JA4 — от curl, это красный флаг. Бот.
AWS WAF Bot Control добавил JA4 в мае 2024. Правило звучит как «TLS fingerprint mismatch» и весит в scoring-модели около 40 баллов из 100. Превысил порог — получил капчу.
Данные из публичного отчёта Cloudflare за Q1 2024: из 100% запросов, помеченных как «automated», 62% были отсеяны именно по несоответствию JA4 и User-Agent. Ещё 23% — по поведенческим факторам. Остальные 15% — по IP-репутации.
Вот как выглядит проверка на стороне nginx с модулем `nginx-ja4` (неофициальный, но рабочий):
```nginx
http {
ja4_zone zone=ja4:10m;
map \$http_user_agent \$expected_ja4_prefix {
~*Chrome "t13d1516h2";
~*Firefox "t13d1715h2";
~*Safari "t13d1517h2";
default "";
}
server {
listen 443 ssl;
if (\$ja4 !~ "^\${expected_ja4_prefix}") {
set \$bot_score "\${bot_score}40";
}
}
}
```
Модуль читает ClientHello на этапе `ssl_client_hello` и пишет результат в переменную `\$ja4`. Дальше — обычная логика WAF.
Почему прокси не спасает
Прокси меняет IP. Иногда — геолокацию. Но TLS-рукопожатие формирует клиент, а не прокси. Если вы гоните curl через SOCKS5-прокси, ClientHello до сервера доходит ровно в том виде, в котором его собрал curl. Прокси только перекладывает байты.
Есть исключение — MITM-прокси с подменой TLS. Тогда ClientHello формирует сам прокси. Но это работает, только если у вас есть валидный сертификат на целевой домен, то есть вы контролируете корневой CA на клиенте. Для внешнего антифрода это неприменимо.
Второе исключение — прокси, который сам терминирует TLS и пересобирает ClientHello. Такие есть, но их собственный JA4 становится отпечатком. Если это nginx на Ubuntu с дефолтным `ssl_protocols TLSv1.2 TLSv1.3` — он выдаст свой характерный JA4, и антифрод это тоже знает.
Что делать, если нужно маскироваться
Вариант первый — использовать реальный браузер через headless. Playwright с Chromium даёт настоящий JA4 Chrome. Минус — вес и скорость. Один запрос — 200-400 мс накладных расходов против 20-30 мс у curl.
Вариант второй — подменить TLS-стек в клиенте. Для Python есть библиотека `curl_cffi`, которая использует BoringSSL с настройками, имитирующими Chrome:
```python
from curl_cffi import requests
response = requests.get(
"https://example.com",
impersonate="chrome124",
proxies={"https": "socks5://user:pass@proxy.example.com:1080"}
)
print(response.status_code)
```
`impersonate="chrome124"` выставляет cipher suite, порядок расширений, GREASE, ALPN и даже параметры Kyber так, чтобы JA4 совпал с реальным Chrome 124. Проверено на `tls.peet.ws` — отпечаток совпадает побайтово.
Для Go есть `utls` с пресетами:
```go
package main
import (
"fmt"
"io"
"net/http"
tls "github.com/refraction-networking/utls"
)
func main() {
config := &tls.Config{ServerName: "example.com"}
conn, _ := tls.Dial("tcp", "example.com:443", config,
&tls.HelloChrome_120)
defer conn.Close()
req, _ := http.NewRequest("GET", "https://example.com", nil)
req.Write(conn)
buf := make([]byte, 4096)
n, _ := conn.Read(buf)
fmt.Println(string(buf[:n]))
}
```
`HelloChrome_120` собирает ClientHello идентично Chrome 120. JA4 будет `t13d1516h2_...` — тот же, что у настоящего браузера.
Грабли, на которые наступают все
Первая — версия браузера в impersonate не совпадает с User-Agent. Вы ставите `impersonate="chrome120"`, а UA пишете от Chrome 124. Антифрод сравнивает версию TLS-стека с версией в UA. Chrome 120 не шлёт `encrypted_client_hello` в том же виде, что 124. Мелкое расхождение — и вы в списке подозрительных.
Вторая — HTTP/2 фреймы. JA4 покрывает только TLS-рукопожатие. Но после него идёт HTTP/2, и там свой отпечаток — Akamai fingerprint (набор фреймов SETTINGS, WINDOW_UPDATE, PRIORITY). curl и Chrome шлют разные SETTINGS. curl по умолчанию: `HEADER_TABLE_SIZE=4096, ENABLE_PUSH=0, MAX_CONCURRENT_STREAMS=100`. Chrome: `HEADER_TABLE_SIZE=65536, ENABLE_PUSH=0, MAX_CONCURRENT_STREAMS=1000, INITIAL_WINDOW_SIZE=6291456`. Разница в 15 раз по окну. Антифрод видит и это.
Третья — timing. Chrome шлёт ClientHello через 0-2 мс после TCP SYN. curl — через 5-15 мс, потому что сначала резолвит DNS, потом открывает сокет. Если вы через прокси, добавляется ещё 30-80 мс на прокси-хендшейк. Паттерн «медленный ClientHello» — отдельный сигнал.
Сводка по цифрам
JA4 в 2024-м — стандарт де-факто. Его поддерживают Cloudflare, AWS WAF, Akamai, Fastly, Imperva. Покрытие — примерно 70% публичных сайтов с антибот-защитой.
Стоимость ошибки: несовпадение JA4 и UA добавляет 30-50 баллов в bot score. Порог капчи — обычно 60-70. Один только JA4 не забанит, но в сумме с другими факторами — легко.
Для легального парсинга через прокси (например, lexic.ml даёт IPv6-пулы с ротацией) важно понимать: прокси решает проблему IP-репутации, но не проблему отпечатка. Нужны оба слоя. curl_cffi + резидентный прокси = рабочая связка. Голый curl + любой прокси = 403 через 5-10 запросов.
Проверить свой JA4 можно на `tls.peet.ws/api/all` — там покажет и JA4, и Akamai fingerprint, и HTTP/2 SETTINGS. Запустите один раз с curl, один раз с curl_cffi — увидите разницу своими глазами.
