todo/protocols/shadowtls.md

date	tags	aliases	link
2026-07-25	протоколы shadowtls restls tls dpi	ShadowTLS Shadow-TLS Restls	https://github.com/ihciah/shadow-tls

🎭 ShadowTLS и Restls: маскировка чужим TLS-рукопожатием

[!info] О чём заметка Разбор ShadowTLS — обёртки, которая прячет произвольный прокси (обычно protocols/shadowsocks) за настоящим TLS-рукопожатием с посторонним сайтом, и родственного протокола Restls. Здесь: как работает трюк с перенаправлением рукопожатия, чем отличаются версии v1–v3, почему в 2025 году v3 признали обнаружимым и что из этого следует практически. Карта протоколов — в protocols/00-overview.

TL;DR

• Идея ShadowTLS: рукопожатие делается с настоящим чужим сайтом, а после его завершения соединение переключается на скрытый прокси-сервер. Наблюдатель видит сертификат и параметры реального популярного ресурса.
• Это близкий родственник xray/reality по замыслу («прикрыться чужим доменом»), но с другой конструкцией и другой историей.
• Версии росли по защищённости: v1 — базовый трюк, v2 — проверка клиента по схеме «запрос-ответ» и упаковка данных, v3 — аутентификация по предварительно разделённому ключу (PSK) и контроль целостности сообщений рукопожатия.
• v3 не считается надёжным с 2025 года: инструмент Aparecium показал, что «подкрашивание» сообщений HMAC удлиняет ServerFinished на 4 байта — достаточный признак для обнаружения. Дата объявления — 31 мая 2025.
• Restls — независимый протокол с той же целью, созданный в ответ на отсутствие взаимной аутентификации в ShadowTLS v2; поддерживает и TLS 1.2, и TLS 1.3, за счёт чего устроен сложнее.
• Поддержка в ядрах есть (Clash/02-mihomo, sing-box/sing-box-extended), но выбирать ShadowTLS как основную защиту в 2026 году — сомнительное решение; рассматривайте xray/reality и protocols/anytls.

Трюк: рукопожатие с одним сервером, данные — с другим

Основная механика ShadowTLS понятна из последовательности действий.

Клиент подключается к вашему серверу-релею и начинает обычное TLS-рукопожатие, но адресованное не ему, а какому-нибудь настоящему популярному сайту. Релей эти сообщения честно пересылает на выбранный сайт и возвращает клиенту его ответы. Для наблюдателя это выглядит абсолютно нормально: настоящий сертификат настоящего домена, корректные параметры, всё сходится — потому что это и есть настоящее рукопожатие с настоящим сервером.

Как только рукопожатие завершено, релей перестаёт пересылать трафик на сайт-прикрытие и соединяет клиента со скрытым прокси (например, сервером protocols/shadowsocks). Дальше внутри уже течёт полезная нагрузка.

Проще говоря: ShadowTLS занимает у настоящего сайта его «лицо» на время знакомства, а разговор ведёт уже свой. Смысл в том, что при пассивном наблюдении соединение неотличимо от визита на популярный ресурс: сертификат чужой и настоящий, свой домен не нужен, следов в логах прозрачности сертификатов вы не оставляете.

Тот же замысел лежит в основе xray/reality, но реализация у них разная, и разошлись они в первую очередь по устойчивости к тонким различиям в поведении.

Три версии и что каждая чинила

v1 реализовывала базовый трюк без аутентификации клиента. Слабость очевидна: любой, кто узнал адрес и порт, мог подключиться и получить нестандартное поведение — то есть сервер выдавал себя при активной проверке.

v2 добавила проверку клиента по схеме «запрос-ответ» и упаковку данных в вид, похожий на обычные TLS-записи Application Data. Стало лучше, но исследователи указали на отсутствие взаимной аутентификации: клиент не мог убедиться, что говорит именно со своим релеем, что открывало путь к атакам посредника со стороны цензора.

v3 переработала оба слоя. Аутентификация строится на предварительно разделённом ключе (PSK), а сообщения второй части рукопожатия (ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished) релей возвращает от настоящего сервера, «подкрашивая» их значением HMAC(PSK) — это одновременно и подтверждение подлинности релея, и контроль целостности. Подробности — в описании протокола v3.

Почему v3 больше не считается надёжным

Здесь и находится главный практический вывод заметки.

Приём с «подкрашиванием» имеет побочный эффект: добавление HMAC меняет длину сообщений — в частности, ServerFinished оказывается на 4 байта длиннее, чем в нормальном TLS-рукопожатии. Наблюдателю не нужно ничего расшифровывать: достаточно измерить длину конкретного сообщения и сравнить с эталоном.

Именно это и показал инструмент Aparecium — открытый proof-of-concept для обнаружения протоколов, маскирующихся под TLS. По его данным, 31 мая 2025 года ShadowTLS v3 был объявлен обнаружимым из-за врождённого свойства конструкции, а не из-за ошибки в конкретной реализации. Раньше, в 2023 году, независимый анализ безопасности ShadowTLS (FOCI 2023) уже разбирал слабые места ранних версий.

[!danger] Практический вывод по ShadowTLS Если ваша схема обхода опирается на ShadowTLS как на основную маскировку, считайте, что у цензора есть готовый способ её распознать — публично описанный и реализованный в открытом инструменте с мая 2025 года. Это не значит, что она перестанет работать завтра: обнаружимость и блокировка — разные вещи, и многое зависит от того, что именно применяет ваша сеть. Но планировать на ShadowTLS новую установку в 2026 году не стоит — разумнее xray/reality или protocols/anytls.

Заодно это хорошая иллюстрация общего правила: маскировка живёт ровно до тех пор, пока её конструкция не создаёт собственного признака. Любая добавка к стандартному протоколу — лишние байты, изменённая длина, нестандартный порядок сообщений — потенциально становится сигнатурой. Тот же принцип объясняет, почему DPI/browser-ja4-fingerprint-block так ценен для DPI.

Restls: соседний ответ на ту же задачу

Restls (репозиторий 3andne/restls, авторское описание — «Restls: A Perfect Impersonation of TLS») создавался как ответ на конкретный недостаток ShadowTLS v2 — отсутствие взаимной аутентификации. Его отличия:

• Взаимная аутентификация встроена в само рукопожатие и, по замыслу автора, не добавляет новых наблюдаемых признаков.
• Поддержка и TLS 1.2, и TLS 1.3. ShadowTLS v3 в строгом режиме работает только с серверами на TLS 1.3, а Restls умеет выдавать себя за более широкий круг сайтов — ценой заметно более сложной конструкции.
• Сервер может изображать любой сайт из разрешённого списка, а клиент — обычный браузер.

В экосистеме ядер Restls появляется как опция обфускации: в релизах Clash/02-mihomo середины 2026 года поддержка restls добавлена для AnyTLS, VMess, VLESS и Trojan. Отдельного независимого анализа устойчивости Restls, сопоставимого по глубине с работами по ShadowTLS, в открытом доступе немного — относитесь к нему как к перспективному, но недостаточно проверенному варианту.

Как это выглядит в конфиге

ShadowTLS — не самостоятельный прокси, а обёртка: в конфиге он задаётся как отдельный слой, поверх которого работает основной протокол. Типичная связка — Shadowsocks поверх ShadowTLS: указывается адрес релея, домен сайта-прикрытия (handshake server), версия протокола и пароль/PSK. Версия обязана совпадать на обеих сторонах.

Из ядер обёртку поддерживают Clash/02-mihomo (в том числе для Snell в свежих релизах) и sing-box/sing-box-extended; в xray/project-x реализации нет — ещё один пример того, как редкие позиции в списке поддержки определяют выбор ядра (см. Clash/08-vs-sing-box).

📚 См. также

• protocols/00-overview — карта задач и поддержки в ядрах.
• xray/reality — та же идея прикрытия чужим сайтом, но иначе устроенная и активно развивающаяся.
• protocols/anytls — современный ответ на детект «TLS внутри TLS».
• protocols/shadowsocks — протокол, который чаще всего заворачивают в ShadowTLS.
• DPI/browser-ja4-fingerprint-block — почему мелкие отклонения в рукопожатии выдают инструмент.
• VLESS/dpi-tls-june-2026 — общая картина методов детекта.
• 🔗 ihciah/shadow-tls — исходники и описание версий протокола.
• 🔗 Chasing Shadows: A security analysis of the ShadowTLS proxy (FOCI 2023) — независимый анализ безопасности.

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.