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:

  • Ваш 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:

  • Python github.com/alexbers/mtprotoproxy
  • Erlang github.com/seriyps/mtproto_proxy/tree/fake-tls
  • Обратите внимание: на момент написания статья — функционал 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 — это бесплатно для вас усилит защиту.

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

    Оставить комментарий