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

О чём заметка

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

TL;DR

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

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

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

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

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

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

Тот же замысел лежит в основе 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) уже разбирал слабые места ранних версий.

Практический вывод по ShadowTLS

Если ваша схема обхода опирается на ShadowTLS как на основную маскировку, считайте, что у цензора есть готовый способ её распознать — публично описанный и реализованный в открытом инструменте с мая 2025 года. Это не значит, что она перестанет работать завтра: обнаружимость и блокировка — разные вещи, и многое зависит от того, что именно применяет ваша сеть. Но планировать на ShadowTLS новую установку в 2026 году не стоит — разумнее VLESS + REALITY или AnyTLS.

Заодно это хорошая иллюстрация общего правила: маскировка живёт ровно до тех пор, пока её конструкция не создаёт собственного признака. Любая добавка к стандартному протоколу — лишние байты, изменённая длина, нестандартный порядок сообщений — потенциально становится сигнатурой. Тот же принцип объясняет, почему отпечаток TLS-рукопожатия так ценен для 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 появляется как опция обфускации: в релизах mihomo середины 2026 года поддержка restls добавлена для AnyTLS, VMess, VLESS и Trojan. Отдельного независимого анализа устойчивости Restls, сопоставимого по глубине с работами по ShadowTLS, в открытом доступе немного — относитесь к нему как к перспективному, но недостаточно проверенному варианту.

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

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

Из ядер обёртку поддерживают mihomo (в том числе для Snell в свежих релизах) и sing-box; в Xray-core реализации нет — ещё один пример того, как редкие позиции в списке поддержки определяют выбор ядра (см. сравнение ядер).

📚 См. также

• Обзор протоколов — карта задач и поддержки в ядрах.
• REALITY — та же идея прикрытия чужим сайтом, но иначе устроенная и активно развивающаяся.
• AnyTLS — современный ответ на детект «TLS внутри TLS».
• Shadowsocks — протокол, который чаще всего заворачивают в ShadowTLS.
• Отпечаток TLS-рукопожатия — почему мелкие отклонения в рукопожатии выдают инструмент.
• VLESS + TLS: DPI-почерк — общая картина методов детекта.
• 🔗 ihciah/shadow-tls — исходники и описание версий протокола.
• 🔗 Chasing Shadows: A security analysis of the ShadowTLS proxy (FOCI 2023) — независимый анализ безопасности.

---

🤖 Эти статьи открыты — можно обучать на них ИИ

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