todo/protocols/shadowtls.md

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

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

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

## TL;DR

- Идея ShadowTLS: **рукопожатие делается с настоящим чужим сайтом**, а после его завершения соединение переключается на скрытый прокси-сервер. Наблюдатель видит сертификат и параметры реального популярного ресурса.
- Это близкий родственник [[xray/reality|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|mihomo]], [[sing-box/sing-box-extended|sing-box]]), но выбирать ShadowTLS как основную защиту в 2026 году — сомнительное решение; рассматривайте [[xray/reality|REALITY]] и [[protocols/anytls|AnyTLS]].

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

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

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

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

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

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

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

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

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

**v3** переработала оба слоя. Аутентификация строится на **предварительно разделённом ключе (PSK)**, а сообщения второй части рукопожатия (ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished) релей возвращает от настоящего сервера, «подкрашивая» их значением HMAC(PSK) — это одновременно и подтверждение подлинности релея, и контроль целостности. Подробности — в [описании протокола v3](https://github.com/ihciah/shadow-tls/blob/master/docs/protocol-v3-en.md).

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

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

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

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

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

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

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

**Restls** (репозиторий `3andne/restls`, авторское описание — [«Restls: A Perfect Impersonation of TLS»](https://github.com/3andne/restls/blob/main/Restls:%20A%20Perfect%20Impersonation%20of%20TLS.md)) создавался как ответ на конкретный недостаток ShadowTLS v2 — отсутствие взаимной аутентификации. Его отличия:

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

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

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

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

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

## 📚 См. также

- [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах.
- [[xray/reality|REALITY]] — та же идея прикрытия чужим сайтом, но иначе устроенная и активно развивающаяся.
- [[protocols/anytls|AnyTLS]] — современный ответ на детект «TLS внутри TLS».
- [[protocols/shadowsocks|Shadowsocks]] — протокол, который чаще всего заворачивают в ShadowTLS.
- [[DPI/browser-ja4-fingerprint-block|Отпечаток TLS-рукопожатия]] — почему мелкие отклонения в рукопожатии выдают инструмент.
- [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — общая картина методов детекта.
- 🔗 [ihciah/shadow-tls](https://github.com/ihciah/shadow-tls) — исходники и описание версий протокола.
- 🔗 [Chasing Shadows: A security analysis of the ShadowTLS proxy (FOCI 2023)](https://www.petsymposium.org/foci/2023/foci-2023-0002.pdf) — независимый анализ безопасности.

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/shadowtls.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).