Что такое Fake TLS: как работает FakeTLS изнутри? — SEO блог оптимизатора из ПМР: про технологии и продвижение сайтов

Какие проблемы решает Fake TLS? Когда Deep Packet Inspection (DPI) анализирует трафик, он смотрит не только на порты, но и на сигнатуры протоколов — характерные байтовые паттерны в начале соединения. Например, Shadowsocks или другой прокси-трафик, даже зашифрованный, имеет статистически случайный вид — энтропия слишком высокая, нет типичной структуры «настоящего» протокола. Для DPI это красный флаг.

Fake TLS решает эту задачу иначе: притвориться настоящим TLS-соединением настолько убедительно, чтобы DPI не отличил его от обычного HTTPS.

Архитектура на уровне байтов

Настоящий TLS Handshake (для сравнения)

В реальном TLS клиент начинает с ClientHello:

16 03 01 [length] 01 [length] ...
│  │  │            │
│  │  └─ TLS 1.0  └─ HandshakeType = ClientHello
│  └─ Major version
└─ ContentType = Handshake (22 = 0x16)

Внутри ClientHello находятся:

список поддерживаемых cipher suites
список расширений (extensions)
SNI (Server Name Indication) — домен, к которому подключается клиент
случайные 28 байт (Random field)

Что делает Fake TLS

Fake TLS копирует эту структуру байт в байт, но вместо случайных данных в поле Random или в других нестандартно используемых полях — прячет реальную полезную нагрузку.

Типичная схема:

[ Легитимный ClientHello заголовок ]
[ SNI = какой-то реальный домен    ]  ← например, www.microsoft.com
[ Random (28 байт) = зашифр. данные] ← здесь и прячется payload
[ Остаток extensions — стандартный ]

Этапы соединения

1. Инициализация (Client → Server)

Клиент (например, локальный прокси-клиент) формирует синтетический ClientHello:

Берёт реальный fingerprint браузера (Chrome, Firefox) — список cipher suites, порядок extensions, значения grease — чтобы пройти JA3/JA3S fingerprinting
В поле Random (32 байта, из которых 4 — это unix timestamp, 28 — случайные) зашифровывает служебные данные: идентификатор сессии, ключ, нужный upstream-адрес
SNI выставляется в реальный легитимный домен (называется camouflage domain или cover domain)

2. Обработка на сервере

Сервер Fake TLS получает пакет. Он не является настоящим TLS-сервером — он просто умеет разобрать этот пакет как TLS:

Парсит структуру ClientHello
Извлекает данные из поля Random (или из SessionID, или из другого поля — зависит от реализации)
Расшифровывает их своим ключом
Понимает: это не реальный TLS, это туннель

3. Ответ сервера (Server → Client)

Сервер отвечает синтетическим ServerHello:

[ ServerHello с легитимной структурой ]
[ Certificate — реальный или поддельный сертификат для cover domain ]
[ Зашифрованные данные в нестандартных полях ]

Некоторые реализации идут дальше и отвечают реальными TLS-данными от настоящего сервера (например, делают реальный TLS-запрос к Microsoft и проксируют его ответ), чтобы соединение выглядело полностью аутентично при глубоком анализе.

4. Установка туннеля

После «рукопожатия» обе стороны переходят в режим обмена данными. Трафик оборачивается в TLS Record Layer:

17 03 03 [length] [encrypted payload]
│  │  │
│  │  └─ TLS 1.2
│  └─ Major
└─ ContentType = Application Data (23 = 0x17)

Реальный зашифрованный туннельный трафик прячется внутри Application Data records. Для DPI это выглядит как обычная HTTPS-сессия.

Ключевые техники обхода DPI

Техника	Цель
JA3 fingerprint mimicry	Скопировать точный fingerprint реального браузера
SNI camouflage	Использовать SNI легитимного домена
Реальный сертификат	Предъявить валидный TLS-сертификат для cover domain
GREASE values	Добавить RFC-специфичные значения-заполнители как настоящий браузер
Record size имитация	Разбивать данные на record’ы типичного для браузера размера
Timing	Соблюдать временны́е паттерны, характерные для TLS

Разница между реализациями

uTLS-based (Go) — библиотека uTLS позволяет буквально «надеть маску» конкретного браузера. Вы говорите: «притворись Chrome 120» — и библиотека генерирует байт-в-байт идентичный ClientHello.

REALITY (используется в XRay/Sing-box) — продвинутая версия: сервер делает реальный TLS-хендшейк с внешним сервером и переиспользует его параметры. Клиент, который не знает секрета, видит абсолютно легитимный TLS до реального сайта.

Простой Fake TLS — просто копирует структуру заголовков, не заботясь о fingerprint. Легко детектируется JA3-анализом.

Слабые места

Если cover domain недоступен или DPI проверяет, что сертификат реально принадлежит заявленному SNI — могут быть проблемы
Анализ длины и timing’а пакетов может выявить несоответствие реальному HTTPS-трафику
Active probing: цензор сам подключается к серверу и проверяет, ведёт ли он себя как настоящий TLS-сервер для заявленного домена. REALITY решает эту проблему — обычный Fake TLS нет.

Fake TLS — это не шифрование, это стеганография на уровне протокола: данные прячутся не в картинке, а в структуре сетевого рукопожатия. Чем точнее имитация — тем сложнее детектирование. Современные реализации (REALITY, uTLS с реальным fingerprint) достигли уровня, когда статистически отличить их от браузерного HTTPS крайне затруднительно без активного зондирования.