Telegram тестирует новый вариант обхода блокировок — маскировка трафика под обычный TLS (https).
Предистория: Попытки заблокировать Telegram происходят в разных странах, первый вариант блокировки был простым — блокировка IP адресов серверов Telegram.
Telegram достаточно успешно отбивается от этой отаки, переодически меняя IP с которых он доступен, однако это вызывает долгий первичный Connecting…
Чуть позднее стали доступны Socks прокси, однако протокол не подразумивает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.
Следующим раундом стал — выпуск MTProto Proxy — прокси сервера от Telegram, который использует свой протокол MTProto, однако и он обладал некоторыми проблемами — размер пакетов достаточно характерный и специфичный, и многие DPI начали определять Telegram уже после первого пакета — блокируя доступ.
Ответом на такое поведение стало введение новой версии протокола MTProto — с случайной длинной, теперь определить что перед нами Telegram туннель — сложнее, часть DPI начали классифицировать трафик как «другое» часть все же научились выявлять характерный паттер и с некоторой вероятностью (не 100%) определять, что трафик относится к Telegram
Сейчас мы переходим на следующий этап (похоже финальный или пред-финальный) — стеганография.
Стеганогра́фия (от греч. στεγανός «скрытый» + γράφω «пишу»; букв. «тайнопись») — способ передачи или хранения информации с учётом сохранения в тайне самого факта такой передачи (хранения).
Другими словами — теперь Telegram будет притворятся обычным TLS (https) трафиком.
Зачем притворяться?
Ответ лежит на поверхности — в нынешнее время, большая часть трафика — TLS (https), при использовании данного протокола вот что увидит ваш провайдер или DPI:
- Ваш IP
- IP Сервера
- Домен подключения (URL не увидит)
Причем над последним пунктом ведется активная работа, что бы его убрать и помимо двух IP был просто шифрованный туннель с неизвестным содержимым.
В такой ситуации все не стандартные протоколы начинают привлекать к себе дополнительное внимание и решение этой проблемы — одно — если ты выглядишь как TLS (https) то вопросов становится меньше.
Техническая реализация
При использовании нового протокола, поток MTProto оборачивается в стандартный HTTPS (первые сообщения о согласовании туннеля) в котором идет передача домена (ненастоящего). После согласования протокола MTProto — Fake-TLS не используется, далее трафик начинает ходит привычным нам MTProto протоколом со случайной длинной (dd — ключи).
Справочно: Telegram использует 3 вида ключей для MTProto Proxy:
- обычные ключи (Легко определяется DPI)
- первые две буквы — dd — случайная длина сообщений (DPI может определить протокол только по первым пакетам согласования подключения — далее выглядит как обычный https/TLS)
- первые две буквы — ee — Fake TLS + случайная длина сообщений (DPI не может определить протокол, первое сообщение и все последующие выгледят как HTTPS/TLS)
Где попробовать?
Уже есть два Proxy сервера, которые поддерживают новый стандарт (официального прокси сервера всё еще нет, хотя он и в прошлый раз достаточно долго добавлял поддержку dd ключей)
Поддерживающие режим Fake TLS Proxy:
Обратите внимание, на момент написания статья — функционал fake tls — эксперементальный, следовательно надо использовать Beta или Alpha версии ПО (как прокси так и клиентов)
Какие клиенты поддерживают новый режим?
Бета версии Telegram Desktop, Telegram iOS и говорят, стабильная версия на Android.
Как попробовать?
- Для примера будет использован прокси на Python:
- Устанавливаем Proxy:
git clone https://github.com/alexbers/mtprotoproxy.git; cd mtprotoproxy - Запускаем:
python3 mtprotoproxy.py - В консоль будет выведен ключ с припиской (experimental) — он нам и нужен
tg: tg://proxy?server=8.8.8.8&port=443&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t (experimental) - Вводим данные в клиент как обычно — поздравляю, теперь вы используете новый режим Fake TLS.
Что происходит за кулисами?
Сейчас оба прокси сервера используют домен Google.com при подключении, другими словами ваш провайдер или DPI будет видеть HTTPS коннект к Google.com но IP будет — вашего сервера, в будущем авторы прокси обещают сделать ввод других доменов и возможность непускать клиентов, если они используют другой домен при согласовании подключения.
Обратите внимание! Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com
Почему Fake TLS — это хорошо ?
Как уже ранее было сказано — при использовании HTTPS протокола ваш провайдер или DPI может руководствоватся только двумя критериями при блокировке соединения:
- IP Сервера
- Домен
Причем последний пункт скоро пропадет (спасибо eSNI).
Переход прокси на Fake TLS делает его невидимым для вашего провайдера, а если сервер стоит в облаке от, скажем, Google и при согласовании используется какой-то домен Google — тогда и эвистический анализ не поможет, со стороны все будет выглядеть так, как буд-то какой-то сервис Google работает по HTTPS/TLS протоколу.
Минусы есть?
Небольшие, но есть — если мы будем обращатся к прокси используя браузер — соединение ожидаемо не установится (секрета то нет). Со стороны это будет выглядеть, как некорректно настроенный HTTPS сервер. Может ли это быть критерием для блокировки? — нет, сервер може ожидать например личного сертификата или другой информации.
Помимо этого — в будущем можно будет помимо секрета использовать связку секрет+домен (ненастоящий) в качестве поля аутентификации и если к серверу будет обращение с другим доменом — показывать вполне обычный сайт, а вот если с доменом который известен только вам — поднимать туннель MTProto.
Однако это станет возможным только после внедрения eSNI (шифрованного заголовка домена) — сейчас он передается без шифрования.
Есть куда расти ?
Конечно есть, на мой взгляд Telegram еще не использовал все средства для скрытия, помимо https/TLS имеет смысл использовать WebSocket для скрытия трафика — это еще сильнее усложнит идентификацию и классификацию трафика.
Заключение
Если у вас есть свой MTProto прокси сервер — изучите новый его стандарт, как только во всех публичных версиях Telegram клиентов он станет доступным — переведите всех пользователей на него.
Да, есть небольшая проблема — придётся обновить строку подключения у всех (секрет) он меняется, однако это позволит повысить успешность скрытия прокси.
Помимо перевода на новый стандарт — стоит перевести прокси на 443 порт (стандартный для HTTPS) и заблокировать не шифрованные подключения (ключи без dd и ee), а после миграции всех на ee вариант и dd ключи в том числе, благо прокси это умеют.
Так же не лишним будет установить перед прокси балансировщик с определением домена и при запросе домена отличного от настроенного в прокси — показывать вполне настоящий сайт, как только будет внедрён стандарт eSNI — это бесплатно для вас усилит защиту.
Вам также может быть интересно
- SSLH: Прячем SSH/HTTPS/OpenVPN/Telegram за единым портом 443
- Telegram выпустил официальный MTProto Proxy Server
Автор: Shift
