Telegram спрятал MTProxy в обычный HTTPS

22 августа Telegram Desktop 7.1.0 получил WEB-прокси, который для DPI выглядит куда неприятнее обычного MTProxy: соединение уходит на HTTPS-сайт через 443 порт.

В changelog это прошло одной сухой строкой: "Add new WEB proxy type to connection settings". До релиза следы нашли в коммите 96d63afc в tdesktop, после него Telegram быстро выпустил фикс 7.1.1. Формально добавили еще один тип прокси. По факту Telegram аккуратно завернул MTProxy в веб-транспорт так, чтобы снаружи это напоминало посещение нормального сайта.

Подробности по релизу и разбору схемы уже появились у SecurityLab о WEB-прокси Telegram и в новости на Хабре про новый WEB-прокси.

MTProxy остался прежним, поменялась упаковка

В обсуждениях уже вижу типичную ошибку: WEB-прокси называют новым MTProxy. Это неверно.

Клиент Telegram по-прежнему поднимает соединение по правилам MTProxy, с его секретом и шифрованием. Но готовый зашифрованный поток теперь можно отправить не напрямую на MTProxy-сервер, а через встроенный WebView по HTTPS/WebSocket на домен, который снаружи выглядит как обычный сайт.

Для DPI картина меняется радикально. Он видит TLS-сессию к домену на 443 порту, а не отдельный подозрительный прокси-протокол. Открываете этот домен в браузере без нужных параметров - получаете нормальную домашнюю страницу. Передаете корректные параметры - срабатывает служебная bridge-страница, которая прокидывает поток дальше.

Для фильтров это неприятная развилка. Заблокировать IP или SNI такого домена можно, но вместе с прокси под блокировку попадает живой сайт. Чем больше таких доменов и чем правдоподобнее их публичная часть, тем дороже становится грубая блокировка.

Веб-слой возит поток, но не лезет в DATA

Внутри Telegram добавил компактный протокол мультиплексирования. В нем есть кадры OPEN, DATA, WINDOW, CLOSE, PING/PONG, HELLO/WELCOME. Их задача практичная: вести несколько логических соединений через один WebSocket, контролировать поток, открывать и закрывать каналы, проверять живость транспорта.

На серверной стороне опубликован tproxy-server. Он принимает поток из WebView, разбирает его на отдельные соединения и передает локальному MTProxy. При этом содержимое DATA серверу расшифровывать не требуется.

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

Вместо секрета сервер выдает временный 256-битный токен. Bridge-страница открывается только при корректных параметрах. Без них пользователь видит обычный сайт, а не страницу с очевидным сообщением в стиле "здесь работает прокси".

Bridge-страницу посадили в клетку не для красоты

Встроенный WebView в такой схеме сразу вызывает правильную паранойю. Если страница внутри клиента умеет читать cookies, дергать localStorage, подключать внешние скрипты или просить доступ к буферу обмена, транспорт быстро превращается в лишнюю поверхность атаки.

Telegram эту часть урезал жестко. У bridge-страницы нет cookies, localStorage, IndexedDB, Service Workers, внешних ресурсов, форм, доступа к камере, микрофону и буферу обмена. В таком дизайне страница должна быть трубой для трафика, а не маленьким браузером со всеми привычными веб-возможностями.

Что уже есть в клиентах

На Android реализация идет через Android System WebView. Для iOS заявлен WKWebView. Также зарезервированы t.me/webproxy и схема tg://webproxy, но маршрут пока не обрабатывается.

Есть деталь, которую я бы не пропускал при планировании инфраструктуры: tproxy-server официально помечен как proof-of-concept. Запускать его как готовую коммерческую основу без аудита, логирования, защиты от злоупотреблений и нагрузочных тестов - плохая идея.

VPN-сервисам придется смотреть на это без снисхождения

Для VPN-бизнеса история болезненная по двум причинам.

Первая - Telegram забирает сценарий "мне нужен только мессенджер". Если пользователю не нужен полный VPN, а надо открыть один Telegram, встроенная настройка выглядит проще отдельного приложения и подписки. Особенно под ударом простые прокси-сервисы, которые продавали доступ именно под мессенджеры.

Вторая - Telegram показал рабочий чертеж обфускации. Домен отдает легитимный контент, транспорт идет по HTTPS/WebSocket, полезная нагрузка остается зашифрованной исходным протоколом, bridge-страница не торчит наружу как публичная прокси-точка. Для сервисов обхода блокировок это почти техническое задание на следующую версию маскировки.

Но романтизировать схему не надо. Маскировка под сайт не делает инфраструктуру бессмертной. Домены можно искать по поведению, повторяющимся WebSocket-шаблонам, несоответствию между контентом сайта и сетевым профилем, ошибкам в реализации. Если операторы начнут массово копировать один proof-of-concept без изменений, их будут находить пачками.

Блокировка дорожает, а прокси придется взрослеть

У многих старых схем обхода была одна слабая точка: трафик выглядел как трафик обхода. WEB-прокси Telegram делает другую ставку - выглядеть как обычный сайт и заставлять блокировщика принимать более дорогие технические и политические решения.

Для VPN-команд практический сигнал прямой. Если продукт до сих пор держится на логике "дадим пользователю сервер и порт", этого уже мало. Нужны домены с реальным контентом, аккуратный WebSocket-транспорт, изоляция веб-слоя, короткоживущие токены и аудит клиентской части.

Telegram 22 августа не закрыл тему прокси. Он поднял минимальную планку маскировки, и теперь слабые реализации будут выглядеть устаревшими еще до первого серьезного блокирования.

P.S. Больше свободы в сети - заходите в бот

По разработке ботов - пишите в личные сообщения