uTLS и JA3 fingerprint: как VPN обходит DPI в 2026

Когда говорят, что «VPN-протокол VLESS Reality неотличим от обычного HTTPS-соединения к microsoft.com», на самом деле речь идёт о двух разных слоях маскировки. Первый — содержимое TLS-handshake’а: SNI, сертификат, ALPN. Второй — fingerprint самого TLS-клиента: какие cipher suites он предлагает, в каком порядке, какие расширения добавляет. Если первый слой не подделать — DPI увидит подозрительный SNI и зарежет. Если не подделать второй — DPI увидит «странный TLS-клиент, который не похож ни на Chrome, ни на Firefox» и тоже зарежет.

В этой статье разбираем второй слой — JA3-fingerprinting и библиотеку uTLS, которая делает VPN-клиенты неотличимыми от настоящего браузера.

Что такое JA3 fingerprint

JA3 — это алгоритм fingerprinting’а TLS-клиента, опубликованный командой Salesforce в 2017 году. Идея простая: разные TLS-клиенты (Chrome, Firefox, OpenSSL, curl, Go-стандартный crypto/tls) формируют ClientHello по-разному. По полям ClientHello — версии TLS, списка cipher suites, расширений, эллиптических кривых и форматов точек — можно вычислить MD5-хэш, который идентифицирует клиент с точностью до версии.

Например (упрощённо):

• Chrome 122 на Windows — JA3 хэш cd08e31494f9531f560d64c695473da9
• Firefox 124 на Linux — b32309a26951912be7dba376398abc3b
• Стандартный curl без флагов — 771,4866-4867-...
• OpenVPN-client — характерный набор, отличающийся от любого браузера

JA4 — это модернизация 2023 года от FoxIO, с более устойчивым форматом и дополнительными данными (включая ALPN и SNI extension). Стандарт постепенно вытесняет JA3 в DPI-системах.

Для ТСПУ JA3/JA4-fingerprint — один из основных инструментов классификации. Даже если SNI указывает на легитимный сайт, аномальный JA3-хэш (например, JA3 от Go-стандартной библиотеки) выдаёт нестандартный клиент — и соединение режется.

Почему стандартные библиотеки палятся

Большинство VPN-инструментов написаны на Go, Rust или Python. Эти языки имеют свои реализации TLS — crypto/tls в Go, rustls или native-tls в Rust, ssl в Python. Каждая реализация формирует ClientHello своим способом, отличающимся от Chrome.

Конкретные примеры:

• Go crypto/tls — характерный набор cipher suites в определённом порядке. JA3-хэш стандартного Go-клиента давно известен ТСПУ.
• curl без флагов — использует OpenSSL, JA3 как у командной строки. На «обычный браузер» не похож.
• wget — то же самое.
• openvpn-client — собственная TLS-реализация поверх OpenSSL с уникальным набором cipher suites.
• wg-quick (WireGuard) — не использует TLS, но первый UDP-пакет имеет фиксированную сигнатуру (148 байт + magic bytes).

Если VPN-клиент написан «в лоб» на crypto/tls, его TLS-handshake детектируется DPI за миллисекунды, даже если SNI и сертификат идеально замаскированы под легитимный сайт.

uTLS — библиотека для подделки JA3

uTLS — форк Go-стандартной библиотеки crypto/tls, разработанный с 2017 года в проекте refraction-networking. Основной автор — Sergey Frolov (University of Colorado), активно поддерживается контрибьюторами anti-censorship community.

Что делает uTLS: позволяет программно собрать ClientHello, в точности повторяющий fingerprint Chrome / Firefox / Safari / iOS-нативного клиента. Список cipher suites, порядок расширений, эллиптические кривые, размер padding’а — всё конфигурируется так, чтобы JA3-хэш совпадал с известным браузерным.

В библиотеке есть готовые пресеты: HelloChrome_120, HelloFirefox_120, HelloSafari_16_0, HelloIOS_14. Разработчик VPN-клиента подключает uTLS вместо стандартного crypto/tls и одной строкой выбирает, под какой браузер маскироваться:

conn := utls.UClient(rawConn, &utls.Config{...}, utls.HelloChrome_120)

С точки зрения DPI трафик становится неотличим от Chrome’а той же версии — JA3-хэш совпадает, порядок расширений совпадает, ALPN совпадает.

Какие VPN-клиенты используют uTLS

На 2026 год uTLS — стандартная зависимость практически всех современных anti-DPI VPN-движков:

• xray-core — движок для VLESS, Trojan, Shadowsocks. uTLS активно используется в реализации Reality: при handshake к публичному домену (microsoft.com) клиент уподобляется Chrome’у новой версии, и JA3-фингерпринт совпадает.
• v2ray-core — predecessor xray-core. Тоже использует uTLS, но конфигурация чуть сложнее.
• sing-box — универсальный proxy-движок, поддерживает uTLS из коробки для VLESS, Trojan, ShadowTLS.
• Hysteria 2 — использует TLS 1.3 поверх QUIC. uTLS-эквивалент для QUIC — библиотека quic-go с патчами для подделки fingerprint’а QUIC-handshake’а (поле transport parameters, версия QUIC, размер первого Initial-пакета).
• NaiveProxy — proxy от Klzgrad, в чистом виде использует chromium-network-stack (это уже не uTLS, а настоящий Chrome как HTTP/3-клиент, что даёт идеальный fingerprint, но огромный binary).

Все эти движки внутри клиентов вроде AmneziaVPN, Hiddify, NekoBox, V2RayN, Karing обеспечивают, что TLS-handshake VPN-клиента к серверу выглядит как handshake обычного Chrome’а к microsoft.com.

Что это даёт пользователю в РФ

Конкретный пример работы Reality + uTLS на МТС в Москве, 2026:

1. Пользователь запускает Hiddify, выбирает Durev VPN или собственный VPS.
2. Клиент инициирует TLS-соединение к VPN-серверу. В ClientHello:
   • SNI: www.microsoft.com (один из whitelist-доменов в конфиге Reality).
   • JA3-fingerprint: идентичен Chrome 124 на Windows (через uTLS preset HelloChrome_124).
   • ALPN: h2, http/1.1 — как у обычного браузера.
3. Сервер видит ClientHello, проверяет Reality-подпись клиента, признаёт его легитимным.
4. Установлен TLS-канал. Внутри — VPN-команды.
5. ТСПУ видит TLS-handshake к www.microsoft.com с JA3 как у Chrome. Никакого повода для блокировки.

Альтернативный сценарий без uTLS: тот же VPN, но клиент использует стандартный crypto/tls. ТСПУ видит SNI www.microsoft.com, но JA3 — Go-style. Это аномалия: обычный пользователь Microsoft не ходит на сайт с Go-клиента. Соединение режется.

Можно сказать так: Reality без uTLS — это маскарад в правильном костюме, но с неправильным лицом. С uTLS — костюм и лицо совпадают.

Чего uTLS не умеет

Подделка JA3 — необходимое, но не достаточное условие неотличимости. Есть несколько классов атак, которые uTLS закрыть не может:

TLS-in-TLS detection

Если внутри TLS-сессии передаётся ещё одна TLS-сессия (классический сценарий: VPN-клиент проксирует HTTPS-запрос пользователя через VPN-туннель), DPI может это заметить по специфической структуре зашифрованного трафика — длины пакетов, тайминги, ритм TCP-сегментов. Эта атака описана академически с 2019 года, и GFW Китая её активно использует.

ТСПУ к 2026 году TLS-in-TLS-эвристики ещё массово не применяет, но это вопрос времени. Защита — на уровне транспорта (padding, fragmentation на стороне xray-core).

Active probing

DPI может сам отправить TLS-handshake к подозрительному серверу и посмотреть, что он отвечает. Если сервер ответит «не как настоящий microsoft.com» (например, не подгрузит ассеты, не вернёт реальную HTML-страницу) — раскроется.

Reality защищается от active probing’а через прозрачный reverse-proxy: если клиент не предоставил валидную Reality-подпись, сервер просто проксирует запрос настоящему microsoft.com. Trojan-GFW защищается через настоящий fallback-веб-сервер (обычно nginx с дефолтной страницей). Без этой защиты любой stealth-протокол палится за неделю.

Поведенческий анализ

Даже если handshake идеален, ритм трафика выдаёт. Обычный пользователь Microsoft заходит на сайт, грузит несколько HTML/CSS/JS, идёт дальше. Пользователь VPN — держит длинное соединение часами, гонит через него весь трафик. По duration + bandwidth + content-pattern можно классифицировать без анализа handshake’а.

Защита частичная: split-tunneling (не весь трафик через VPN), несколько IP-адресов в ротации, фрагментация сессий. Это не маскировка handshake’а, а маскировка поведения.

Будущее: ECH и MASQUE

JA3-fingerprinting — это эпоха TLS 1.2 и раннего TLS 1.3. Следующее поколение протоколов закрывает саму возможность fingerprint’а на уровне стандарта.

ECH (Encrypted Client Hello)

ECH — это расширение TLS 1.3, при котором весь ClientHello (включая SNI, ALPN, расширения) шифруется ключом сервера, опубликованным в DNS. На уровне TLS-handshake’а ТСПУ видит только зашифрованный ClientHello — и не может узнать ни домен, ни fingerprint клиента.

ECH катит Cloudflare с 2024 года, частично — Google и Firefox. На 2026 году ECH остаётся в стадии draft (draft-ietf-tls-esni-22), но движется к финальному RFC. Когда ECH станет универсальным, VPN-клиентам больше не нужно будет подделывать JA3 — настоящий ClientHello будет скрыт от DPI криптографически.

MASQUE

MASQUE — драфт IETF для туннелирования произвольного TCP/UDP через HTTP/3 CONNECT-method. Идея: VPN-туннель становится обычным HTTP/3-соединением к серверу. Cloudflare использует MASQUE в продакшене для WARP с 2024 года.

Если MASQUE станет массовым, любая обфускация уровня JA3 потеряет смысл — VPN-трафик неотличим от любого HTTP/3-трафика, потому что это и есть HTTP/3-трафик.

Итог

• JA3-fingerprint — алгоритм идентификации TLS-клиента по полям ClientHello. ТСПУ использует JA3/JA4 для классификации VPN-трафика.
• uTLS — Go-библиотека, позволяющая VPN-клиенту подделать JA3 любого браузера. Используется в xray-core, sing-box, hysteria-2 — фактически во всех современных anti-DPI движках.
• Без uTLS даже идеальная маскировка SNI и сертификата не работает — Go-style JA3-fingerprint выдаёт VPN-клиент за секунды.
• uTLS не закрывает всё — TLS-in-TLS detection, active probing, поведенческий анализ требуют отдельных защит на уровне xray-core, sing-box и серверной конфигурации.
• Будущее — ECH (Encrypted Client Hello) и MASQUE снимут проблему fingerprint’а на уровне стандарта. На 2026 году оба в стадии разворачивания.

Связанные статьи

• VLESS Reality в 2026 — что это такое и почему пробивает блокировки
• ТСПУ в 2026 — что это такое и как работает DPI Роскомнадзора
• VPN-протоколы 2026: какой выбрать для России — полный гид
• VPN в России 2026: полный гид по обходу блокировок