Telegram готовит WEB Proxy: как новый транспорт маскирует MTProxy под обычный HTTPS

Telegram экспериментирует с новым типом прокси, который переносит привычный MTProxy внутрь веб-транспорта. Проект пока остаётся proof-of-concept, но его архитектура уже опубликована в открытом репозитории tproxy-server и позволяет довольно подробно понять, как всё устроено.

Главная идея проста: сам MTProxy никуда не исчезает и его шифрование не меняется. Telegram-клиент сначала формирует обычный зашифрованный MTProxy-поток, а затем передаёт эти данные через встроенный WebView по каналу, внешне похожему на обычное веб-соединение.

Схему можно представить так:

Telegram → локальный WEB Proxy адаптер → WebView → HTTPS/WebSocket → tproxy-server → MTProxy → Telegram

На стороне клиента каждое соединение Telegram превращается в отдельный логический поток. Несколько таких потоков затем объединяются в одну сессию WebView.

Для мультиплексирования разработчики используют собственный набор кадров:

Получается своеобразный транспортный слой поверх обычного HTTPS или WebSocket. При этом tproxy-server не расшифровывает содержимое DATA — для него это просто набор байтов. На сервере данные разделяются обратно на отдельные соединения и передаются локальному официальному MTProxy.

WEB Proxy использует HTTPS на порту 443. Причём сервер может одновременно обслуживать настоящий сайт.

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

Telegram при этом не отправляет сам секрет в JavaScript. Клиент локально вычисляет необходимое значение, открывает bridge-страницу, а сервер выдаёт временный токен для дальнейшей работы сессии.

После этого основной транспорт уже работает через выбранный сервером carrier.

В проекте предусмотрено несколько способов доставки данных:

Какой вариант использовать, решает серверный профиль, а не пользователь. Это позволяет менять транспортную схему без ручной настройки клиента.

Причём «один WebView» не означает один HTTP-запрос. Речь идёт об одном логическом WebView-транспорте и одной авторизованной relay-сессии, внутри которой может находиться множество потоков.

Здесь Telegram сохранил важное разделение функций.

MTProxy по-прежнему отвечает за собственное шифрование, а WEB Proxy выступает транспортной оболочкой. tproxy-server получает уже подготовленные MTProxy-данные и передаёт их дальше.

Более того, relay не получает от клиента произвольный адрес назначения. Он соединяет потоки только с настроенным на сервере официальным MTProxy. Поэтому WEB Proxy нельзя просто превратить в открытый HTTP/SOCKS-прокси для доступа к любым сайтам.

Интересна и защита самой bridge-страницы.

Встроенному веб-компоненту оставили только функции, необходимые для работы транспорта. В частности, проект не использует:

По сути, bridge-страница превращается в максимально урезанный интерфейс между Telegram и веб-транспортом. Это уменьшает количество возможностей, которыми потенциально мог бы воспользоваться вредоносный сервер.

Разработчики отдельно предусмотрели сценарий, при котором на том же домене работает полноценный веб-сайт.

Это может быть:

При обычном посещении пользователь получает сайт. Запрос с неправильным bridge-параметром также должен выглядеть как обычный запрос к сайту. Только корректная комбинация параметров позволяет получить служебную страницу транспорта.

Такой подход важен не только для удобства. Если все WEB Proxy-серверы выглядели бы одинаково, их было бы значительно проще находить автоматическими проверками.

Сейчас проект находится на экспериментальной стадии.

Telegram Desktop уже получил скрытый WebView-транспорт, работающий на уровне процесса, а также предусмотрен вариант с системным браузером в качестве резервного механизма.

Для Android существует экспериментальная реализация на базе Android System WebView. Для iOS подготовлен план реализации через WKWebView. При этом серверный протокол и формат кадров остаются общими для разных платформ.

Для WEB Proxy также предусмотрен собственный формат ссылки:

Но пока есть ограничение: веб-интерфейс t.me ещё не зарегистрировал полноценный маршрут /webproxy, поэтому привычная ссылка «нажал и подключился» пока не стала рабочим публичным механизмом.

По сути, разработчики добавляют ещё один уровень транспорта поверх уже существующего MTProxy.

Это позволяет сохранить существующее шифрование и при этом изменить то, как соединение выглядит для внешнего наблюдателя: вместо очевидного подключения к прокси появляется веб-трафик через HTTPS или WebSocket на стандартном 443-м порту.

При этом проект пока нельзя воспринимать как готовую замену MTProxy. tproxy-server официально остаётся proof-of-concept, а сроки появления WEB Proxy в стабильном Telegram Desktop разработчики пока не объявили.

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