Дуров объявил "цифровое сопротивление", а сообщество втихую починилo прокси за него
NewsMakerУчастники 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 байт. Для нормального браузера такая конструкция невозможна, а для системы фильтрации служит готовой меткой.
История про «победу 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 байт. Для нормального браузера такая конструкция невозможна, а для системы фильтрации служит готовой меткой.