Дуров объявил "цифровое сопротивление", а сообщество втихую починилo прокси за него
Участники Telemt сравнили хэндшейки Chrome и Telegram, вычислили аномалии и принесли готовое решение раньше официальной команды.
История про «победу Telegram над блокировками» в последние дни разошлась по лентам слишком бодро. По версии многих каналов и СМИ, команда мессенджера быстро закрыла уязвимость в прокси и вернула пользователям доступ. Разбор, который обсуждают в техническом сообществе на Habr, рисует совсем другую картину: ключевое срочное исправление появилось не после внутренней работы Telegram, а после того, как энтузиасты сами нашли сигнатуры для DPI (Deep Packet Inspection — глубокая инспекция пакетов), проверили гипотезы на живых сетях и принесли готовое решение.
Слухи о том, что российские ТСПУ (технические средства противодействия угрозам) рано или поздно возьмутся за Telegram-прокси, ходили с начала 2026 года. По словам участников сообщества, у Telegram было несколько месяцев, чтобы проверить реализацию MTProxy и обновить маскировку FakeTLS. Однако 1 апреля фильтрация всё-таки ударила по встроенному механизму обхода: у многих пользователей в России прокси перестали работать, соединения начали обрываться, а часть клиентов просто перестала подключаться.
Пока публика ждала официального ответа, за работу взялись участники сообщества вокруг прокси-сервера Telemt. Схема оказалась прямолинейной: исследователи сравнили рукопожатие по протоколу TLS (Transport Layer Security — протокол защиты транспортного уровня) реального Chrome, которое сеть пропускала, с рукопожатием Telegram, которое фильтры резали, а затем начали по одному менять поля пакета и смотреть, в какой точке поведение сети меняется. Так удалось локализовать признаки, по которым Telegram-трафик детектировался на стороне DPI.
Через сутки, как утверждают авторы разбора, картина стала понятной. Первая проблема сидела в идентификаторе расширения: Telegram отправлял значение 0xFE02, которое давно выглядит как рудимент из старых черновиков, тогда как современный трафик использует актуальные кодовые точки, например 0xFE0D для Encrypted Client Hello (ECH). Вторая проблема выглядела ещё грубее: код объявлял 32-байтный публичный ключ X25519, но фактически генерировал только 20 байт. Для нормального браузера такая конструкция невозможна, а для системы фильтрации служит готовой меткой.
Авторы находок оформили результаты в запрос на включение изменений (pull request) #30513, где описали, что именно нужно поменять и почему. После обсуждения в сообществе сопровождающий (мейнтейнер) Telegram Desktop внёс фиксацию (коммит) 407bf19 с лаконичным комментарием про исправление частей генерации ClientHello и ссылкой на «широкие обсуждения в интернете» и тот самый запрос. В технической среде такой шаг восприняли как запоздалое признание: готовое решение уже лежало на столе, оставалось только забрать минимальный набор правок и влить в код.
На фоне этого исправления особенно болезненно прозвучал другой вывод из обсуждения. По словам участников этого запроса, те же ошибки сохраняются не только в настольном клиенте, но и в tdlib, на которой завязаны мобильные клиенты и сторонние библиотеки. Если оценка верна, исправление получил только Telegram Desktop, а Android, iOS и часть экосистемы вокруг tdlib по-прежнему могут оставаться заметными для фильтрации по тем же признакам.
Добавил напряжения и пост Павла Дурова, где речь шла о давлении на Telegram, миллионах пользователей в России и готовности «со своей стороны» делать трафик мессенджера менее заметным для блокировок. Для сообщества, которое в тот момент уже разобрало проблему по байтам и передало готовый рецепт, такая формулировка прозвучала как попытка присвоить чужую работу. Главная претензия сводится не к самому посту, а к разрыву между публичной риторикой и инженерным процессом: громкие слова появились уже после того, как техническую часть сделали посторонние разработчики.
Даже сторонники исправления не называют случившееся полноценным решением. В разборе перечислены и другие признаки, которые могут выдавать Telegram-трафик: фиксированная длина ClientHello, постоянная длина ECH-нагрузки в рамках одного процесса, устаревшие кодовые точки отдельных расширений, неестественно ровные интервалы между пакетами, механические размеры TLS-записей и, наконец, расхождение между тем, что клиент обещает на этапе ALPN (Application-Layer Protocol Negotiation — согласование протоколов прикладного уровня), и тем, что реально передаёт после рукопожатия. На бумаге соединение выглядит как HTTP/2 или HTTP/1.1, а внутри туннеля идёт сырой MTProto. Для углублённого анализа трафика такой разрыв сам по себе превращается в поведенческую сигнатуру.
Поэтому нынешнее срочное исправление решает только самый острый участок аварии. Современные системы фильтрации давно смотрят не только на отдельные байты в ClientHello, но и на тайминги, размеры записей, форму потока и статистику соединений. Замена двух строк в генераторе пакетов помогает пережить текущую волну блокировок, но не снимает главный вопрос: почему критичные аномалии в FakeTLS жили так долго и почему исправление пришлось приносить извне.
В сухом остатке получилась история не столько о «цифровом сопротивлении», сколько о привычном пользовательском удобстве. Миллионам людей нужен не политический манифест, а рабочий мессенджер для семейных чатов, домовых обсуждений, фотографий, открыток и рабочей переписки. Техническое сообщество, судя по опубликованному разбору, занялось именно этой задачей: не сочиняло красивые лозунги, а искало конкретные сигнатуры, проверяло исправления у провайдеров и возвращало связь тем, кому Telegram нужен каждый день.