🧬 AnyTLS: протокол против детекта «TLS внутри TLS»

О чём заметка

Разбор протокола AnyTLS — относительно нового (2025) прокси, спроектированного вокруг одной конкретной проблемы: характерного почерка, который возникает, когда шифрованное соединение прячут внутри другого шифрованного соединения. Здесь: в чём суть проблемы, как AnyTLS с ней борется набивкой и пулом сессий, чем он отличается от XTLS Vision и где его границы. Карта протоколов — в обзоре.

TL;DR

  • Проблема: когда прокси-протокол работает внутри TLS, у трафика появляется узнаваемый ритм — «рукопожатие внутри рукопожатия», характерные размеры первых пакетов. DPI ловит это, не расшифровывая ничего.
  • Ответ AnyTLS: настраиваемая схема набивки (padding), которая меняет размеры записей на уровне открытого текста до шифрования, плюс мультиплексирование нескольких потоков в одном TLS-соединении и пул готовых сессий, чтобы не создавать новое соединение на каждый запрос.
  • Набивка по умолчанию описана явно: первая порция фиксирована в 30 байт, дальше идут ступени 100–400 и 400–500 байт до восьмого уровня. Схему можно переопределить своей.
  • AnyTLS не прикрывается чужим сайтом: ему нужны свой домен и сертификат, как Trojan, а не как REALITY.
  • Поддерживается sing-box и mihomo (и как исходящий, и как входящий), в Xray-core обсуждался, но своей реализации там нет.
  • Проект молодой: протокол дорос до второй версии в 2025 году, оценки эффективности пока предварительные — закладываться на него как на «серебряную пулю» рано.

Проблема: почему «TLS внутри TLS» видно

Разберём подробно, потому что весь смысл AnyTLS — в этой задаче.

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

Но ему и не нужно читать. Ему достаточно смотреть на размеры и тайминги. Обычный визит на сайт начинается с рукопожатия характерного вида и переходит к передаче данных. А в случае прокси сразу после установления внешнего канала внутри идёт ещё одно рукопожатие — со своим узнаваемым набором размеров записей и своим ритмом «запрос-ответ-запрос». Наблюдатель видит зашифрованный поток, у которого первые несколько пакетов складываются в характерную картинку, не встречающуюся при обычном веб-сёрфинге.

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

Известные ответы на проблему различаются по подходу. XTLS Vision (в экосистеме Xray) распознаёт внутреннее рукопожатие и после его завершения перестаёт накладывать второй слой шифрования, передавая данные напрямую — силуэт исчезает, потому что исчезает второе одеяло. AnyTLS идёт другим путём: он оставляет структуру как есть, но меняет её форму набивкой.

Как устроен AnyTLS

Оболочка. AnyTLS заворачивает произвольный прокси-трафик в стандартный TLS — совместимость с обычной TLS-инфраструктурой сохраняется, никаких экзотических расширений не требуется.

Схема набивки (padding scheme). Ключевой механизм: перед шифрованием AnyTLS добивает записи до заданных размеров, разрушая ту самую характерную последовательность. Схема по умолчанию, по документации протокола, устроена ступенями: первая порция фиксирована в 30 байт, для небольших данных используется набивка 100–400 байт, для средних и крупных — цепочки 400–500 байт, и так до восьмого уровня (stop=8), после чего набивка прекращается. Схему можно заменить своей — в этом смысл названия: вы управляете тем, как выглядит поведение вашего трафика.

Сессии и мультиплексирование. AnyTLS мультиплексирует несколько логических потоков в одном TLS-соединении и держит пул простаивающих сессий со стратегией «использовать самую свежую, вычищать самые старые». Это снижает накладные расходы на установление соединений и заодно убирает ещё один демаскирующий признак: у прокси-клиента иначе получается подозрительно много одинаковых коротких TLS-соединений подряд.

Версия 2 протокола (2025) добавила обратную связь о состоянии сервера и работу с перегрузкой туннеля — это про качество связи, а не про маскировку.

Чего AnyTLS не делает

Здесь важно не переоценить инструмент.

Он не прикрывается чужим сайтом. В отличие от REALITY, AnyTLS не выдаёт себя за постороннего — ему нужен собственный домен и сертификат. Значит, остаются те же следы, что у Trojan: домен зарегистрирован, сертификат попал в публичные логи прозрачности, а сам сервер должен выглядеть правдоподобно для активной проверки.

Он не делает трафик невидимым. Набивка меняет форму, но форма — это статистика, а статистику можно изучать. Разработчики цензурных систем видят те же публичные спецификации и могут строить классификаторы уже под характерное поведение набивки AnyTLS. Независимые оценки протокола пока сдержанные: в обзорном материале Lantern его характеризуют как решение среднего уровня по производительности и обфускации на фоне соседей — то есть как рабочий вариант, а не прорыв.

Он не заменяет транспорт. AnyTLS — про то, как выглядит поток внутри TLS. Проблемы уровня «в сети режут TLS на нестандартных портах» или «UDP заблокирован» он не решает.

Молодой протокол — отдельный риск

AnyTLS появился в 2025 году, его вторая версия вышла в том же году, и объём независимого анализа пока невелик. У молодых протоколов регулярно находят и ошибки реализации, и неучтённые демаскирующие признаки — так было и с ShadowTLS, чья третья версия считалась устойчивой, пока в 2025 году не показали обратное. Используйте AnyTLS как один из вариантов в арсенале, а не как единственную опору, и обновляйте ядро.

Где поддерживается и как настраивается

Реализации: эталонная anytls-go, а также порты на Rust. Из ядер AnyTLS поддерживают sing-box и mihomo — в последнем и как исходящее подключение, и как слушатель (то есть mihomo может быть сервером AnyTLS). В Xray-core протокол обсуждался в issue-трекере, но собственной реализации нет — это как раз тот случай, когда список поддержки протоколов определяет выбор ядра.

Настройка со стороны клиента минимальна: адрес, порт, пароль, домен для TLS и, при желании, своя схема набивки. Именно последнее отличает AnyTLS от большинства протоколов: параметр маскировки вынесен в конфиг, и его можно менять, не меняя протокол.

📚 См. также

  • Обзор протоколов — карта задач и поддержки в ядрах.
  • VLESS + TLS: DPI-почерк — подробно о проблеме, ради которой AnyTLS создан.
  • XTLS и Vision — альтернативный ответ на ту же проблему в экосистеме Xray.
  • ShadowTLS — другой подход к маскировке под TLS и история его обнаружения.
  • Trojan — протокол с похожими требованиями (свой домен и сертификат).
  • Возможности и протоколы mihomo — как AnyTLS выглядит в YAML-конфиге.
  • 🔗 anytls/anytls-go — эталонная реализация и документация протокола.

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

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