Транспорт Standard TLS

Использование реальных доменных имен и подлинных сертификатов. Базовый метод сокрытия прокси в потоке штатного защищенного веб-серфинга (HTTPS).

Требует домен?

Да (Обязательно)

Шифрование

TLS 1.2 / TLS 1.3

Защита от сканирования

Через Fallback (Отдача сайта)

Сложность настройки

Средняя (нужен Certbot/ACME)

1. История: Прятки на порту 443

В первые годы борьбы с "Золотым щитом" (GFW) прокси-серверы вроде Shadowsocks работали на случайных портах (например, 8388) и использовали собственную криптографию. Со временем DPI научились легко вычислять такой трафик — нераспознанный зашифрованный поток на высоких портах вызывал подозрение и блокировался.

В ответ сообщество создало протокол Trojan. Его философия была невероятно простой: «Самый безопасный способ пронести данные — притвориться тем, что DPI пропускает всегда». Этим "белым" трафиком был HTTPS (TLS). Trojan заставил пользователей покупать собственные домены и вешать на них реальные сертификаты от Let's Encrypt. Трафик пошел строго через порт 443, и для DPI это стало выглядеть так, словно пользователь просто просматривает свой личный сайт.

2. Механика работы и защита через Fallback

Чтобы обман сработал, недостаточно просто зашифровать пакеты в TLS. Цензор может в любой момент открыть ваш домен my-vpn-domain.com через обычный браузер (Active Probing). Если он увидит ошибку 400 Bad Request или странную обрывочную строку — IP-адрес будет заблокирован.

Для решения этой проблемы была придумана система Fallback (Резервное перенаправление).

[ Входящее TLS соединение (Порт 443) ] | [ Ядро Xray / sing-box ] | Проверка первого пакета (Есть ли секретный UUID?) | +-----------------------+-----------------------+ | | [Да, это клиент] [Нет, это браузер/бот] | | Расшифровка туннеля (VLESS) Fallback: Перенаправление трафика | на локальный веб-сервер (Nginx:80) Выход в свободный интернет | Отдача реального HTML-сайта (блог, страница-заглушка)

Благодаря Fallback-архитектуре, ядро Xray-core само слушает порт 443. Оно терминально расшифровывает TLS. Если пароль верный, данные идут в интернет. Если пароля нет (пришел бот или проверяющий), Xray невидимо перебрасывает этот запрос на Nginx, который крутится локально, и тот отдает красивую заглушку веб-сайта.

3. Слабое место: "Матрешка" двойного шифрования

Несмотря на изящность схемы, стандартный TLS имеет фундаментальный изъян — проблему TLS-in-TLS (двойное шифрование).

Когда вы заходите на условный `youtube.com` через свой VPN, браузер шифрует соединение (первый TLS). Затем ваш VPN-клиент упаковывает этот уже зашифрованный пакет в свой туннель и шифрует его во второй раз (Standard TLS до вашего домена).

Сигнатуры длин пакетов

Машинное обучение ТСПУ умеет анализировать эту "матрешку". DPI видит, что внутри внешнего TLS-соединения происходит характерный скачок длин пакетов, типичный для вложенного TLS-рукопожатия (ClientHello). Эта аномалия позволяет выявлять прокси-серверы даже без активного зондирования.

Именно для устранения этой уязвимости позже была разработана технология XTLS Vision, которая "вырезает" внутреннее шифрование, отправляя данные напрямую (Splice).

4. Вердикт: Использовать ли Standard TLS сегодня?

Ключевые преимущества

Прозрачная и понятная архитектура: вы полностью контролируете свой домен и сертификат.
Идеально работает с CDN (Cloudflare), так как это стандартный HTTPS.
При наличии качественного сайта-заглушки (Fallback) надежно защищает сервер от активного зондирования.

Технические нюансы

Требует покупки домена, настройки DNS (A-записей) и автоматизации обновления сертификатов (ACME/Cron).
Без использования XTLS Vision (или REALITY) уязвим к эвристическому анализу TLS-in-TLS.
Оверхед на шифрование выше, чем у легковесных Stateless-решений.