shadow-tls и domain fronting: спрятать VPN за чужим TLS

Идея пряча VPN-трафик за чужим HTTPS-handshake’ом не нова. Domain fronting появился в 2010-х, VLESS Reality — в 2023, shadow-tls — в 2022 как промежуточный шаг. Все три решают одну задачу — сделать так, чтобы DPI видел соединение к легитимному публичному сайту, а внутри шёл совсем другой трафик. Но архитектурно — три разных подхода. Разберём shadow-tls и его отличие от domain fronting’а.

Идея shadow-tls

Берём Shadowsocks-2022 — надёжный AEAD-шифр (2022-blake3-aes-256-gcm или 2022-blake3-chacha20-poly1305), стойкий к replay и активному анализу. Но у Shadowsocks есть проблема: его поток выглядит как равномерно случайный TCP-трафик высокой энтропии. К 2024 году DPI научилось ловить это статистическими методами — даже без явной сигнатуры.

shadow-tls решает проблему так: оборачиваем Shadowsocks-2022 в настоящий TLS 1.3 handshake к стороннему публичному сайту. Снаружи — стандартный HTTPS. Внутри — Shadowsocks.

Конкретно по проводу:

1. Клиент устанавливает TCP-соединение к серверу shadow-tls на порту 443.
2. Клиент шлёт TLS ClientHello с SNI www.bing.com (или другим whitelist’овым доменом из конфига).
3. Сервер shadow-tls сам параллельно идёт к настоящему www.bing.com:443, дёргает оттуда ServerHello + Certificate + ServerFinished и проксирует обратно клиенту.
4. Клиент и сервер заканчивают TLS-handshake. На уровне DPI handshake идентичен реальному.
5. После handshake’а — внутри TLS-канала идёт Shadowsocks-2022 поток.

Для ТСПУ это выглядит так: «TCP-соединение к IP, который выдаёт сертификат www.bing.com. TLS-handshake валидный. JA3 — браузерный (через uTLS). ALPN — h2. После handshake’а — encrypted TLS records». Никакого повода для блокировки.

Что атакующий видит на проводе

Полный лог TLS-сессии с точки зрения DPI:

Client → Server:  TCP SYN
Server → Client:  TCP SYN+ACK
Client → Server:  TCP ACK + TLS ClientHello {
                    SNI: www.bing.com
                    Cipher suites: [chrome-set]
                    ALPN: h2, http/1.1
                    Extensions: [chrome-set, GREASE]
                  }
Server → Client:  TLS ServerHello + Certificate {
                    Subject: CN=www.bing.com
                    Issuer: DigiCert SHA2 Secure Server CA
                    Valid: 2025-09 — 2026-09
                    SAN: *.bing.com, bing.com, www.bing.com, ...
                  } + ServerFinished
Client → Server:  TLS Finished
                  [encrypted records...]

Сертификат настоящий. Issuer — реальный CA. Subject — реальный bing.com. JA3 совпадает с Chrome. ALPN ожидаемый. ТСПУ не находит ничего подозрительного — это просто HTTPS-сессия к Microsoft.

После handshake’а внутри идут зашифрованные TLS records, в каждом из которых сидит Shadowsocks-2022 фрейм. Снаружи невозможно отличить от encrypted HTTP/2-трафика — обе вещи это encrypted TLS records.

Что shadow-tls делает по шагам (v3)

shadow-tls прошёл три версии (v1 — 2022, v2 — конец 2022, v3 — 2023). На 2026 актуальная — v3, она снимает проблемы предыдущих с replay-атаками и raw probe’ом. Ниже — v3:

1. Установка TLS-сессии с замаскированным SNI

Клиент инициирует TCP к серверу shadow-tls и шлёт TLS ClientHello с замаскированным SNI. Список возможных доменов задан в конфиге сервера (handshake_server = ["www.bing.com", "mail.google.com", "www.cloudflare.com"]).

Какой SNI выбрать — решает клиент. Обычно — что-то популярное, имеющее устойчивые сертификаты и активный трафик в стране (чтобы IP-связь была правдоподобной).

2. Сервер shadow-tls делает relay к настоящему сайту

Сервер видит ClientHello, читает SNI = www.bing.com, открывает параллельное TCP-соединение к www.bing.com:443, проксирует туда ClientHello. Получает обратно ServerHello + Certificate + ServerFinished и передаёт клиенту.

Этот relay — критическая часть архитектуры. Без него сервер не мог бы предоставить настоящий сертификат www.bing.com (cert приватный, у настоящего CA подписан), а валидный JA3+cert mismatch DPI бы ловил.

3. Аутентификация через HMAC внутри handshake’а

Чтобы сервер shadow-tls не работал как открытое прокси (т.е. чтобы случайный probe не получил доступ), v3 добавляет аутентификацию внутри TLS-handshake’а. Клиент вставляет HMAC от shared secret в одно из расширений ClientHello. Сервер проверяет HMAC: если валидный — переходит в режим Shadowsocks-relay, если нет — продолжает прозрачный proxy к настоящему bing.com.

Эта проверка происходит до того, как клиент видит ServerHello, и невидима снаружи (HMAC сидит в шифрованной части или в padding’е).

4. Внутри туннеля идёт Shadowsocks-2022

После TLS Finished с обеих сторон клиент и сервер начинают гонять Shadowsocks-2022 фреймы внутри encrypted TLS records. На уровне TLS это выглядит как обычный application data — порциями по 16 KB (TLS record max).

Внутри Shadowsocks: AEAD-шифр (BLAKE3 для key derivation, AES-256-GCM или ChaCha20-Poly1305 для шифра), salt в первом фрейме, защита от replay через timestamp.

5. Сертификат — настоящий

Сертификат, который видит клиент в ServerHello, выпущен настоящим CA (DigiCert, Let’s Encrypt, etc) для настоящего bing.com. Цепочка валидна, OCSP отзывы реальные. На pin-checks из настоящего Chrome’а сертификат бы прошёл.

Это принципиально отличает shadow-tls от self-signed-based VPN’ов, которые палятся сразу: «странный CA, странный CN, никто на свете кроме VPN’ов такое не использует».

Сравнение с Reality

Оба — TLS-маскировка. Но архитектура разная:

Критерий	shadow-tls	VLESS Reality
Транспорт	TCP + TLS handshake-relay	TCP + TLS с украденными SNI+cert
Внутренний протокол	Shadowsocks-2022	VLESS
Где сертификат	Сервер делает relay к реальному сайту на каждый handshake	Сервер один раз получает cert, использует его навсегда
Latency на handshake	+1 RTT (relay добавляет время к каждому соединению)	базовый TLS
Bandwidth overhead	минимальный	минимальный
Сложность настройки	Проще (один конфиг-файл, один порт)	Сложнее (xray-core, ключевая инфраструктура Reality)
Зрелость	v3 в продакшене с 2023	продакшен с 2024
Использование в РФ	Реже (sing-box-based стек)	Чаще (xray-core mainstream)

Reality — более изящный: один-в-один TLS на одном порту, без relay’я. shadow-tls — проще для self-hosted setup: разворачивается одним бинарником, конфиг короткий. Reality требует серьёзной настройки xray-core, понимания SNI-whitelist и fallback’ов.

В целом обе техники сейчас работают параллельно в российском сегменте, но Reality доминирует в коммерческих VPN-сервисах — Durev VPN, PlusOne, Red Shield и ряд других; полный список с тристейтами по операторам — в рейтинге на главной. shadow-tls чаще встречается в self-hosted и в продвинутых китайских V2Ray-сборках.

Domain fronting — родственная, но другая техника

Domain fronting — техника, которую часто путают с shadow-tls, но она работает иначе.

Идея domain fronting:

1. Клиент устанавливает TLS-соединение к большому CDN (Cloudflare, Fastly, Akamai) с SNI популярного сайта (www.example.com), который на этом CDN хостится.
2. После handshake’а внутри HTTP-запроса клиент пишет другой Host: header (vpn-backend.example.com).
3. CDN видит TLS-handshake с SNI=example.com, валидный сертификат, валидный handshake. После расшифровки видит Host=vpn-backend.example.com и роутит запрос к нужному backend’у.

Снаружи (DPI) выглядит как обычный HTTPS к example.com. Внутри (на стороне CDN) идёт к совсем другому хосту.

Проблема: с 2018 Cloudflare выпилил поддержку host-header-not-equal-sni — нельзя больше отправить запрос к Cloudflare-IP с SNI=cloudflare.com и Host=mybackend.com. Cloudflare возвращает 421 Misdirected Request. Google и AWS сделали то же самое в 2018-2020.

Что осталось от domain fronting в 2026:

• Мелкие CDN — некоторые региональные CDN ещё допускают front’инг. Но трафик через них не маскируется под «легитимный Google» — выглядит «соединением к малоизвестному CDN», что само по себе подозрительно.
• Cloudflare Workers / Cloudflare Pages — клиент идёт на ваш Workers-домен на Cloudflare с SNI любого Cloudflare-домена. Это техническая возможность, потому что вся Cloudflare-инфра на одних IP. Используется в обходных решениях.
• Fronting через AWS S3 + CloudFront — частично работает, но AWS активно борется.

В РФ к 2026 domain fronting — нишевая техника. Большинство ушли в Reality, shadow-tls и Hysteria 2.

Чего shadow-tls не защищает

Любая stealth-техника имеет границы. shadow-tls — не исключение.

TLS-in-TLS detection

TLS-in-TLS detection — техника, при которой DPI замечает, что внутри одного TLS-соединения идёт ещё одна TLS-сессия. Структура зашифрованного трафика выдаёт: первые байты после handshake’а имеют распределение, характерное для TLS ClientHello (даже зашифрованного).

shadow-tls внутри гонит Shadowsocks-2022, который не имеет TLS-сигнатуры (просто encrypted bytes). Это защищает от классического TLS-in-TLS detect. Но если пользователь делает HTTPS-запросы через shadow-tls туннель (а это типичный сценарий), внутри сидит ещё одна TLS-сессия — и она потенциально детектируется. ТСПУ к 2026 году TLS-in-TLS массово не применяет, но техника известна, и это вопрос времени.

Active probing

Active probing — DPI сам идёт TLS-handshake’ом к подозрительному серверу, чтобы посмотреть ответ. Если сервер ответит «не как настоящий bing.com» — раскроется.

shadow-tls v3 защищается через transparent fallback: если клиент не предоставил валидный HMAC внутри handshake’а, сервер просто проксирует трафик настоящему bing.com и возвращает его HTML. Probe видит реальный Bing — атака бесплодна.

Без этой защиты любой stealth-протокол палится за неделю-две. v1 и v2 не имели полноценной защиты от probe — поэтому v3 рекомендуется как baseline.

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

Описывается в пилларе про DPI evolution. Длинная сессия + высокий bandwidth + равномерные пакеты выдают VPN даже при идеальном handshake’е. shadow-tls без padding’а на data-уровне здесь уязвим.

Решение — комбинация shadow-tls + sing-boxmultiplex (мультиплексирование нескольких потоков через один TLS), периодические short-lived сессии, шум cover-traffic. На 2026 это редко настраивается «из коробки» — требует ручной конфигурации.

Где shadow-tls используется на практике

• Китайские V2Ray-сборки. shadow-tls появился именно в китайском anti-GFW сообществе (ihciah — китайский разработчик), и там же набрал популярность. Активно используется в self-hosted setup на VPS.
• Self-hosted setup в РФ. Продвинутые пользователи, у которых свой VPS, разворачивают shadow-tls + Shadowsocks-2022 как простую альтернативу полноценному xray-core с Reality.
• sing-box экосистема. sing-box встроенно поддерживает shadow-tls inbound/outbound, и клиенты на его основе (Hiddify, NekoBox, Karing) могут использовать shadow-tls без дополнительной конфигурации.
• Tier-2 коммерческие VPN. Несколько небольших российских сервисов катают shadow-tls параллельно с Reality. Большинство top-tier — на Reality.

Итог

• shadow-tls оборачивает Shadowsocks-2022 в настоящий TLS-handshake с реальным сертификатом стороннего сайта (Bing, Cloudflare). DPI видит обычный HTTPS, внутри — Shadowsocks.
• v3 добавляет HMAC-аутентификацию внутри handshake’а и transparent fallback к настоящему сайту при невалидном клиенте — защита от active probing.
• Domain fronting (родственная техника) после выпиливания у Cloudflare/Google/AWS в 2018-2020 жив только на мелких CDN. В РФ почти не используется.
• vs Reality: shadow-tls проще в настройке, но менее изящный (relay на каждый handshake). Reality чаще встречается в top-tier коммерческих VPN, shadow-tls — в self-hosted и продвинутых сборках.
• Не защищает от: TLS-in-TLS detection (если внутри HTTPS), поведенческого анализа длин пакетов, ML-классификаторов потока. Требует комбинации с padding и cover traffic для полной защиты.

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

• Как ТСПУ выявляет VPN: техническая хроника 2024-2026
• uTLS и JA3 fingerprint: как VPN обходит DPI в 2026
• VPN-протоколы 2026: какой выбрать для России — полный гид
• Padding и junk-пакеты: как AmneziaWG обходит ТСПУ