Trojan-прокси под видом HTTPS: как работает технология и где ломаются обещания невидимости

1920
Trojan-прокси под видом HTTPS: как работает технология и где ломаются обещания невидимости

Trojan в теме VPN и прокси не означает вредоносную программу. Обычно под этим названием понимают Trojan-GFW и совместимые режимы в Xray, sing-box, Trojan-Go и клиентских оболочках. Смысл протокола в том, что соединение выглядит как обычный TLS-сеанс, чаще всего на 443-м порту, а служебные данные Trojan передаются уже внутри зашифрованного канала.

Называть Trojan полноценным VPN не совсем верно. Базовый Trojan работает как TLS-прокси: клиент принимает трафик от приложения или локального SOCKS/HTTP-прокси, открывает TLS-соединение с сервером, передает запрос на целевой адрес и дальше гонит поток через туннель. VPN-клиент может завернуть через Trojan весь трафик устройства, но маршрутизацию, TUN-интерфейс, правила DNS и split tunneling добавляет приложение, а не сам протокол.

Материал предназначен для легального и ответственного изучения сетевых технологий, анализа трафика и корпоративной защиты. Инструкции по обходу блокировок, несанкционированному доступу, слежке, взлому, нарушению правил сервисов и доступу к запрещенным ресурсам здесь не приводятся. В России отдельно регулируют распространение информации о средствах обхода ограничений, поэтому любые практические действия надо проверять по действующим законам и внутренним правилам организации.

Что происходит внутри TLS-соединения

Оригинальная спецификация описывает Trojan довольно просто. Клиент сначала выполняет настоящее TLS-рукопожатие. Если TLS не поднялся, сервер закрывает соединение или ведет себя как обычный HTTPS-сервер. После успешного TLS клиент отправляет внутри зашифрованного канала структуру с хешем пароля и SOCKS5-подобным запросом.

hex(SHA224(password)) CRLF Trojan Request CRLF Payload

Поле hex(SHA224(password)) занимает 56 шестнадцатеричных символов. Затем идет CRLF, запрос с командой CONNECT или UDP ASSOCIATE, типом адреса, адресом назначения и портом. Если сервер принимает пароль и запрос, сервер соединяется с указанным endpoint и открывает прямой туннель между клиентом и целевым узлом.

Важная деталь: первый пакет может содержать не только авторизацию и запрос, но и полезную нагрузку. Такой прием уменьшает количество отдельных сетевых шагов и частично снижает грубую детекцию по длине стартовых пакетов. Но прием не превращает Trojan в обычный браузерный HTTPS. Браузер после TLS обычно загружает HTML, CSS, JavaScript, картинки и шрифты, открывает несколько соединений и ведет себя иначе, чем долгоживущий прокси-туннель.

Что видит внешний наблюдатель

TLS скрывает содержимое передаваемых данных, но не стирает метаданные. Сетевой оператор или корпоративный шлюз обычно видит IP-адрес сервера, порт, время соединения, объемы передачи, направления пакетов, SNI при обычном TLS без ECH, параметры ClientHello, ALPN, сертификатную цепочку и поведение узла при нестандартных запросах.

Именно поэтому тезис «Trojan неотличим от HTTPS» слишком сильный. Более точная формулировка звучит так: Trojan пытается выглядеть как HTTPS на уровне первичного протокола и усложняет простую сигнатурную проверку. Для грубой фильтрации по порту и явному VPN-handshake такой подход работает лучше, чем классический OpenVPN или WireGuard без дополнительной маскировки. Для анализа по TLS fingerprint, статистике потоков, репутации адресов, DNS и таймингам маскировка уже не выглядит абсолютной.

Признак Что скрывает Trojan Что остается видимым
Полезная нагрузка Содержимое внутри TLS Факт длинного шифрованного соединения
Протокол Служебные поля Trojan TLS handshake, ALPN, сертификат, SNI без ECH
Маршрут Конечные запросы от локальной сети IP и домен Trojan-сервера
Поведение клиента Часть признаков обычного прокси Размеры пакетов, ритм обмена, долгие сессии

Fallback помогает, но не делает сервер невидимым

Fallback нужен для активных проверок. Если кто-то подключается к серверу без правильного формата или пароля, сервер может передать соединение обычному веб-сервису. Сканер видит не явный прокси, а сайт или другой легитимный сервис. В Xray режим Trojan поддерживает fallback по тем же принципам, что и VLESS: срабатывание может зависеть от длины первого пакета, 57-го байта и результата аутентификации. Подробности описаны в документации Xray.

Но fallback не стоит считать обязательной броней. Документация sing-box прямо предупреждает, что нет доказательств, будто серверы Trojan надежно выявляют именно по HTTP-ответам, а открытый стандартный http/s-порт на сервере сам может стать заметным признаком. Такой контраргумент полезен: маскировка должна соответствовать реальной модели угроз, а не копировать чужую схему из гайда.

Где Trojan полезен и где обещания расходятся с практикой

Trojan уместен как инженерный прием, когда нужно спрятать явный прокси-протокол за обычным TLS и снизить заметность для простых сигнатур. В корпоративной среде такой подход можно рассматривать для тестовых стендов, исследовательской инфраструктуры, удаленного доступа к своим ресурсам и анализа DPI-поведения. Для таких задач важны сертификаты, журналы, контроль клиентов, ограничение пользователей и понятная модель доверия.

Для анонимности Trojan сам по себе не подходит. Сервер видит пользователя и целевые направления, целевые ресурсы видят сервер, а платежи, аккаунты, cookies, браузерные отпечатки и привычное поведение часто раскрывают человека быстрее, чем сетевой уровень. Протокол маскирует транспорт, но не исправляет плохую операционную безопасность.

Отдельная зона риска связана с CDN и WebSocket. Trojan-Go и некоторые реализации умеют передавать Trojan через WebSocket over TLS, что технически позволяет использовать CDN-посредника. Но такая архитектура меняет доверие. Если TLS завершается на стороне CDN, промежуточный провайдер получает больше технического контроля над потоком, а владелец сервера теряет часть прямой модели «клиент - сервер». Поэтому CDN-схему нельзя описывать как автоматическое усиление безопасности.

Еще одна ошибка связана с актуальностью реализаций. Оригинальный Trojan-GFW и Trojan-Go давно выглядят менее активными, чем Xray и sing-box. В реальных клиентах под словом Trojan могут скрываться разные транспортные слои, uTLS-имитация, multiplexing, WebSocket, разные fallback-правила и разные настройки DNS. Поэтому фраза «у меня Trojan» без указания реализации и транспорта почти ничего не говорит о безопасности.

Trojan является VPN?

В строгом смысле нет. Trojan является TLS-прокси. VPN-режим может появиться в клиентском приложении, если программа направляет через Trojan весь системный трафик и управляет маршрутизацией.

Почему Trojan похож на HTTPS?

Trojan сначала поднимает настоящий TLS-сеанс, обычно с валидным сертификатом и портом 443. Служебный запрос идет уже внутри TLS, поэтому простая проверка видит шифрованное соединение, похожее на HTTPS.

Можно ли обнаружить Trojan без расшифровки трафика?

Да. Расшифровка полезной нагрузки не всегда нужна. Аналитик может смотреть на TLS fingerprint, ALPN, SNI, сертификат, репутацию адреса, размеры пакетов, длительность сессий и реакцию сервера на активные пробы.

Fallback гарантирует защиту от сканеров?

Нет. Fallback помогает отвечать на неправильные подключения как обычный веб-сервис, но сложный анализ может учитывать не только ответ сервера, а всю сетевую картину.

Чем Trojan отличается от вредоносного трояна?

Trojan-протокол маскирует сетевое соединение, а не заражает систему. Риск malware возникает отдельно, когда пользователь скачивает сомнительные клиенты, сборки, профили или установщики из неизвестных источников.

Вывод простой: Trojan полезен как способ упаковать прокси-трафик в настоящий TLS и убрать явные признаки отдельного VPN-протокола. Но HTTPS-маскировка не равна невидимости. Перед публикацией, внедрением или анализом такой схемы нужно смотреть на реализацию, транспорт, сертификаты, DNS, журналы, fallback, доверие к CDN и юридический контекст. Чем громче обещание «не обнаружат никогда», тем выше риск, что перед вами не инженерная оценка, а маркетинговая легенда.

Trojan VPN TLS HTTPS прокси DPI трафик
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.
Секлаб · Биологический риск
Иммунитет её не видит.
Антибиотики не берут.
Её не существует. Пока.
38 учёных против одной бактерии →

Николай Нечепуренков

Я – ваш цифровой телохранитель и гид по джунглям интернета. Устал видеть, как хорошие люди попадаются на уловки кибермошенников, поэтому решил действовать. Здесь я делюсь своими секретами безопасности без занудства и сложных терминов. Неважно, считаешь ты себя гуру технологий или только учишься включать компьютер – у меня найдутся советы для каждого. Моя миссия? Сделать цифровой мир безопаснее, а тебя – увереннее в сети.