Кодик кратко объясняет суть статьи
В Telegram Desktop разрабатывается новый транспорт — WEB Proxy, который маскирует трафик MTProxy под обычный HTTPS/WebSocket-трафик через WebView. Это позволяет обходить блокировки, так как соединение выглядит для провайдера как посещение обычного сайта. Прототип уже реализован, серверная часть (tproxy-server) опубликована как proof-of-concept. WEB Proxy не заменяет MTProxy и не вмешивается в его шифрование: зашифрованный трафик MTProxy инкапсулируется в веб-соединение. Для мультиплексирования нескольких логических потоков используется собственный протокол с кадрами OPEN, DATA, WINDOW, CLOSE, PING/PONG и HELLO/WELCOME. Данные передаются в четырёх режимах (последовательные HTTPS-запросы, раздельные HTTPS-каналы, WebSocket с общим или отдельными соединениями), все — через порт 443. Клиент для подключения использует домен и секрет MTProxy, на основе которых генерируется служебный параметр для загрузки специальной bridge-страницы. После загрузки параметр удаляется из URL, выдаётся временный 256-битный токен. Без правильного параметра сервер показывает обычную домашнюю страницу, что позволяет совмещать прокси с полноценным сайтом. Bridge-страница в WebView работает в строго ограниченной среде: запрещены cookies, локальное хранилище, IndexedDB, Service Workers, доступ к камере, микрофону, файлам и другим привилегиям. Разрешены только скрипт страницы, соединение с тем же доменом и интерфейс связи с клиентом — это снижает риски атак. Функция уже частично реализована в десктопной версии (через WebView и резервно через системный браузер), разработки ведутся для Android и iOS. Настройка пока недоступна для обычных пользователей — ссылка t.me/webproxy не активна. Сроки выпуска в стабильной версии не объявлены.
Содержание
Читайте в Telegram
|
Появились первые подробности реализации нового транспорта WEB Proxy в Telegram Desktop, о разработке которого Код.ру уже рассказывал.
Как пишет SecurityLab, команда мессенджера собрала рабочий прототип и опубликовала серверную часть — tproxy-server, — у которой пока статус proof-of-concept, то есть экспериментального подтверждения концепции.
Схема не заменяет привычный MTProxy и не вмешивается в его шифрование: клиент устанавливает MTProxy-соединение по обычным правилам, а уже готовый зашифрованный поток заворачивается в веб-транспорт через WebView. Веб-компонент отвечает только за доставку данных между клиентом и промежуточным сервером.
Как WEB Proxy передаёт трафик
- Чтобы передавать через одно веб-соединение сразу несколько логических потоков Telegram, разработчики добавили компактный протокол мультиплексирования со своим набором служебных кадров: OPEN открывает соединение, DATA переносит полезные данные, WINDOW сообщает, какой объём информации ещё готов принять получатель (это классический механизм управления окном для защиты от перегрузки), CLOSE завершает поток; PING и PONG нужны для проверки, что канал жив, а HELLO и WELCOME — для установки сессии. У каждого логического потока — своё состояние, и все они уживаются в одном канале.
- Для самой доставки данных предусмотрено четыре режима, между которыми выбирает сервер, а не пользователь.
- Первый — последовательные HTTPS-запросы. Второй — тот же HTTPS, но каждому логическому соединению выделен свой канал. Третий и четвёртый — на базе WebSocket: либо все потоки идут через одно соединение, либо каждому — своё.
- Всё это использует стандартный HTTPS-порт 443, то есть внешне не отличается от обычного веб-трафика. На сервере общий поток принимает сам tproxy-server. Он разбирает канал на отдельные соединения и передаёт каждое локально запущенному официальному MTProxy.
При этом содержимое кадров DATA для tproxy-server остаётся непрозрачным набором байтов — расшифровать трафик MTProxy он не может, а клиент не имеет возможности использовать ретранслятор для подключения к произвольному стороннему адресу. Иными словами, оператор WEB Proxy технически не видит переписку и не превращается в открытый прокси.
Как WEB Proxy маскируется под обычный сайт
Ключевая деталь маскировки — то, как выглядит подключение снаружи.
Клиенту нужны только доменное имя и обычный секрет MTProxy; из этих двух значений Telegram на устройстве вычисляет служебный параметр, необходимый для открытия так называемой bridge-страницы.
Сам секрет в JavaScript-код при этом не передаётся, а после загрузки страницы служебный параметр удаляется из адреса, и сервер выдаёт временный 256-битный токен, которым дальше и подписывается сессия.
Если тот же URL открыть без правильного параметра или со сломанным — сервер отдаст обычную домашнюю страницу.
Владелец домена может держать на нём полноценный сайт со своими страницами, API и пользователями: bridge-страница показывается только тем, у кого есть корректная связка «домен + секрет».
Что WEB Proxy разрешено внутри WebView
Возможности самой bridge-страницы внутри WebView намеренно урезаны почти до нуля — ей запрещены:
- cookies;
- локальное хранилище браузера;
- IndexedDB и Service Workers;
- а также загрузка файлов, всплывающие окна, формы, внешние ресурсы и доступ к камере, микрофону, буферу обмена и прочим разрешениям устройства.
Остаётся только необходимый минимум:
- встроенный в страницу скрипт;
- HTTPS/WebSocket-соединение с тем же доменом;
- специальный интерфейс связи с Telegram Desktop.
Это резко сокращает поверхность атаки на пользователя со стороны недобросовестного сервера.
Когда WEB Proxy появится у пользователей
У десктопного клиента уже есть скрытый транспорт на базе WebView, работающий на уровне всего процесса, и резервный вариант через системный браузер, параллельно готовятся реализации на Android (Android System WebView) и iOS (WKWebView).
Для будущих настроек уже зарезервированы ссылка t.me/webproxy и схема tg://webproxy, но сайт t.me пока не обрабатывает маршрут /webproxy — то есть готового способа настроить WEB Proxy в один клик у обычных пользователей ещё нет.
Сроки появления функции в стабильной версии Telegram Desktop разработчики не называют.
