Технологии цензуры
TLS-in-TLS — детекция вложенного TLS
Атака GFW и Cisco против TLS-туннелей: внешний TLS открывается нормально, но внутри передаётся ещё один TLS-handshake. Эта аномалия детектируется по таймингам и размерам пакетов.
Определение
TLS-in-TLS — это паттерн, при котором внутри уже установленного внешнего TLS-туннеля передаётся ещё один TLS-handshake (обычно к реальной цели пользователя — google.com, github.com). Возникает в любой схеме, где VPN-протокол работает поверх TLS и проксирует пользовательские HTTPS-запросы (классический Trojan-GFW, VLESS+TLS+WS, Shadowsocks-over-TLS).
С точки зрения DPI это аномалия: настоящие веб-клиенты не делают TLS-handshake внутри уже установленного TLS-соединения. Только VPN-туннели.
Как работает
Атака TLS-in-TLS опирается на форму первых байтов, передаваемых внутри внешнего TLS-туннеля. TLS ClientHello имеет узнаваемую структуру:
- байт 0x16 (handshake), 0x03 0x01..0x04 (версия), длина 2 байта;
- затем
ClientHelloсообщение с длиной 2 байта и набором узнаваемых расширений (SNI, supported_groups, ALPN).
Шифрование TLS не меняет длины record-фреймов и не маскирует тайминги. Если первый application-data record внутри внешнего TLS имеет размер ~512–1500 байт и приходит сразу после внешнего handshake — это с высокой вероятностью inner TLS ClientHello.
Известные методы детекции:
- Cisco Encrypted Traffic Analytics (ETA, 2017). Промышленная реализация: SPLT (Sequence of Packet Lengths and Times) + bytes distribution → ML-классификатор.
- GFW (2022 — ). Простая эвристика: после внешнего TLS handshake, если первый record клиента имеет длину, кратную типичному ClientHello, и за ним идёт ответ кратный ServerHello-Cert-цепочке, поток помечается как TLS-in-TLS.
- ТСПУ (2024 — ). Появляется в логах сообщества — конкретные конфигурации Trojan-GFW и VLESS+TLS+WS получают RST через ~5–30 минут.
Атака работает только на пассивном DPI: она не зависит от probing, не требует расшифровки, не нуждается в БД сертификатов.
Почему это важно для пользователя VPN
TLS-in-TLS — главная причина появления XTLS и VLESS Reality. Принципиальная разница:
- Trojan-GFW / VLESS+TLS+WS инкапсулируют пользовательский HTTPS внутри туннельного TLS. Внутри туннеля идёт настоящий TLS-handshake к цели пользователя — это и палится.
- VLESS XTLS Vision. Внутри туннеля передаются только TLS-application-data record’ы пользовательского HTTPS, но без повторного handshake — сам пользовательский TLS «отдан» внешнему туннелю. XTLS Vision прозрачно переписывает первые байты так, чтобы inner TLS handshake выглядел как application-data внешнего TLS. Это и есть «X» в XTLS.
- VLESS Reality + Vision. Reality решает проблему доверия к серверу (active probing), Vision решает проблему TLS-in-TLS на passive DPI. Вместе — стандарт 2026.
Юзеру практически: если ваш VPN-конфиг написан в 2022 году и использует vless + tls + ws, его время ограничено. Рабочая конфигурация на 2026 — vless + reality + xtls-rprx-vision (XTLS Vision).
Связанные термины
DPI — общий класс атак. GFW и ТСПУ — конкретные исполнители. XTLS — расширение протокола, решающее проблему. VLESS Reality — стек, в котором XTLS живёт. Trojan-GFW — старый протокол, уязвимый к TLS-in-TLS.
Источники
- Anderson, McGrew — Identifying Encrypted Malware Traffic with Contextual Flow Data (AISec, 2016) — академический фундамент ETA.
- Cisco — Encrypted Traffic Analytics whitepaper.
- GFW Report — TLS-in-TLS detection (2022) — серия публикаций.
- Документация XTLS Vision — github.com/XTLS/Xray-core.