Telegram наносит ответный удар DPI и блокировкам — Fake TLS

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:

1. Ваш IP
2. IP Сервера
3. Домен подключения (URL не увидит)

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

В такой ситуации все не стандартные протоколы начинают привлекать к себе дополнительное внимание и решение этой проблемы — одно — если ты выглядишь как TLS (https) то вопросов становится меньше.

Техническая реализация

При использовании нового протокола, поток MTProto оборачивается в стандартный HTTPS (первые сообщения о согласовании туннеля) в котором идет передача домена (ненастоящего). После согласования протокола MTProto — Fake-TLS не используется, далее трафик начинает ходит привычным нам MTProto протоколом со случайной длинной (dd — ключи).

Справочно: Telegram использует 3 вида ключей для MTProto Proxy:

1. обычные ключи (Легко определяется DPI)
2. первые две буквы — dd — случайная длина сообщений (DPI может определить протокол только по первым пакетам согласования подключения — далее выглядит как обычный https/TLS)
3. первые две буквы — ee — Fake TLS + случайная длина сообщений (DPI не может определить протокол, первое сообщение и все последующие выглядят как HTTPS/TLS)

Где попробовать?

Уже есть два Proxy сервера, которые поддерживают новый стандарт (официального прокси сервера всё еще нет, хотя он и в прошлый раз достаточно долго добавлял поддержку dd ключей)

Поддерживающие режим Fake TLS Proxy:

1. Python github.com/alexbers/mtprotoproxy
2. Erlang github.com/seriyps/mtproto_proxy/tree/fake-tls

Обратите внимание, на момент написания статья — функционал fake tls — экспериментальный, следовательно надо использовать Beta или Alpha версии ПО (как прокси, так и клиентов)

Какие клиенты поддерживают новый режим?

Бета версии Telegram Desktop, Telegram iOS и говорят, стабильная версия на Android.

Как попробовать?

1. Для примера будет использован прокси на Python:
2. Устанавливаем Proxy:

   git clone https://github.com/alexbers/mtprotoproxy.git; cd mtprotoproxy
   

3. Запускаем:

   python3 mtprotoproxy.py
   

4. В консоль будет выведен ключ с припиской (experimental) — он нам и нужен

   tg: tg://proxy?server=8.8.8.8&port=443&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t (experimental)
   

5. Вводим данные в клиент как обычно — поздравляю, теперь вы используете новый режим Fake TLS.

Что происходит за кулисами?

Сейчас оба прокси сервера используют домен Google.com при подключении, другими словами ваш провайдер или DPI будет видеть HTTPS коннект к Google.com но IP будет — вашего сервера, в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.

Обратите внимание! Коннект будет идти до вашего сервера (IP) а вот в заголовке будет передан домен Google.com

Почему Fake TLS — это хорошо ?

Как уже ранее было сказано — при использовании HTTPS протокола ваш провайдер или DPI может руководствоваться только двумя критериями при блокировке соединения:

1. IP Сервера
2. Домен

Причем последний пункт скоро пропадет (спасибо eSNI).

Переход прокси на Fake TLS делает его невидимым для вашего провайдера, а если сервер стоит в облаке от, скажем, Google и при согласовании используется какой-то домен Google — тогда и эвистический анализ не поможет, со стороны все будет выглядеть так, как буд-то какой-то сервис Google работает по HTTPS/TLS протоколу.

Минусы есть?

Небольшие, но есть — если мы будем обращатся к прокси используя браузер — соединение ожидаемо не установится (секрета то нет). Со стороны это будет выглядеть, как некорректно настроенный HTTPS сервер. Может ли это быть критерием для блокировки? — нет, сервер може ожидать например личного сертификата или другой информации.

Помимо этого — в будущем можно будет помимо секрета использовать связку секрет+домен (ненастоящий) в качестве поля аутентификации и если к серверу будет обращение с другим доменом — показывать вполне обычный сайт, а вот если с доменом который известен только вам — поднимать туннель MTProto.

Однако это станет возможным только после внедрения eSNI (шифрованного заголовка домена) — сейчас он передается без шифрования.

Есть куда расти ?

Конечно есть, на мой взгляд Telegram еще не использовал все средства для скрытия, помимо https/TLS имеет смысл использовать WebSocket для скрытия трафика — это еще сильнее усложнит идентификацию и классификацию трафика.

Заключение

Если у вас есть свой MTProto прокси сервер — изучите новый его стандарт, как только во всех публичных версиях Telegram клиентов он станет доступным — переведите всех пользователей на него.

Да, есть небольшая проблема — придётся обновить строку подключения у всех (секрет) он меняется, однако это позволит повысить успешность скрытия прокси.

Помимо перевода на новый стандарт — стоит перевести прокси на 443 порт (стандартный для HTTPS) и заблокировать не шифрованные подключения (ключи без dd и ee), а после миграции всех на ee вариант и dd ключи в том числе, благо прокси это умеют.

Так же не лишним будет установить перед прокси балансировщик с определением домена и при запросе домена отличного от настроенного в прокси — показывать вполне настоящий сайт, как только будет внедрён стандарт eSNI — это бесплатно для вас усилит защиту.

Вам также может быть интересно

Let's block ads! (Why?)