Его суть — маскировка трафика под обычный TLS (https). Первый вариант блокировки был простым — блокировка IP адресов серверов Telegram. Очевидно, что Telegram достаточно успешно отбивается от этой атаки, периодически меняя IP с которых он доступен.
Чуть позднее стали доступны Socks прокси, однако протокол не подразумевает шифрования и это позволяло достаточно просто смотреть «внутрь» socks туннеля определяя, что внутри него — Telegram, блокируя прокси.
Те пользователи, у которых Telegram перестал работать несмотря на встроенные способы обхода блокировок, стали активно использовать платные и бесплатные VPN и прокси-сервисы. Способ работает и сейчас, лучшие варианты можно подобрать в специальных каталогах, например, RATING-ROXY.INFO, он располагает полной и актуальной базой прокси и VPN серверов.
Следующим раундом стал — выпуск 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 протоколу.