Его суть — маскировка трафика под обычный TLS (https). Первый вариант блокировки был простым — блокировка IP адресов серверов Telegram. Очевидно, что Telegram достаточно успешно отбивается от этой атаки, периодически меняя IP с которых он доступен.

Чуть позднее стали доступны Socks прокси, однако протокол не подразумевает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.

Следующим раундом стал — выпуск MTProto Proxy — прокси сервера от Telegram, который использует свой протокол MTProto, однако и он обладал некоторыми проблемами — размер пакетов достаточно характерный и специфичный, и многие DPI начали определять Telegram уже после первого пакета — блокируя доступ.

Ответом на такое поведение стало введение новой версии протокола MTProto — с случайной длиной, теперь определить что перед нами Telegram туннель — сложнее, часть DPI начали классифицировать трафик как «другое» часть все же научились выявлять характерный паттерн и с некоторой вероятностью (не 100%) определять, что трафик относится к Telegram.

Сейчас мы переходим на следующий этап (похоже финальный или пред-финальный) — стеганография.

Стеганография (от греч. στεγανός «скрытый» + γράφω «пишу»; букв. «тайнопись») — способ передачи или хранения информации с учётом сохранения в тайне самого факта такой передачи (хранения).

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

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

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

Python github.com/alexbers/mtprotoproxy

Erlang github.com/seriyps/mtproto_proxy/tree/fake-tls

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

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

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