Телеграм

Явная недоработка РКН, полетят головы, а потом и премии.

То есть людям из всех утюгов кричат, что приложение вредоносное, но они продолжают им пользоваться?

Вот в теории он же может это сделать ? 1. Встроенный transport-слой с обфускацией. Не просто “прокси”, а протокол, который снаружи выглядит как обычный зашифрованный веб-трафик. Смысл в том, чтобы DPI видел не «ага, это Telegram», а что-то максимально похожее на нормальный TLS/HTTP-трафик. Это один из самых очевидных путей, потому что блокирующий узел обычно ловит не содержимое, а сигнатуры соединения: куда идет трафик, как выглядит рукопожатие, какие размеры пакетов, тайминги, поведение клиента. 2. Domain/fronting-подобные схемы или их современные аналоги. Идея: вход в систему делается через инфраструктуру, которую блокировать дорого и неудобно, потому что вместе с ней можно положить массу легитимного трафика. Исторически такие подходы то работают, то перестают работать — многое зависит от политики CDN и того, что именно режет цензор. Но как класс решений это один из главных вариантов: «спрятать Telegram внутри чего-то массового». 3. Быстрое вращение адресов и маршрутов. Если приложение умеет регулярно получать новые точки входа, менять IP, ASN, диапазоны, балансировать по регионам и провайдерам, блокирующей стороне приходится постоянно догонять. Это не снимает проблему полностью, но сильно повышает стоимость блокировки. 4. Встроенные прокси как часть клиента, а не как ручная настройка. То есть не “пользователь сам ищет proxy”, а клиент сам: • получает список рабочих промежуточных узлов, • проверяет их живость, • переключается между ними, • кэширует резервные каналы. Тогда для пользователя это выглядит как обычное подключение, хотя под капотом идет автоматический failover. 5. Многоступенчатая доставка: bootstrap + relay. Самая сложная часть при жесткой блокировке — не передача сообщений, а первое соединение. Клиенту нужен bootstrap-канал, через который он узнает, куда вообще подключаться. Теоретически это можно решать через несколько независимых каналов распространения конфигурации: встроенные списки, обновляемые ключи, резервные домены, публичные зеркала, внешние каталоги, даже push-каналы. После bootstrap клиент уже может перейти на основной или резервный relay-маршрут. 6. Изменение сетевого поведения клиента. DPI часто цепляется не только за IP/домен, но и за паттерн: длины пакетов, интервалы, очередность сообщений. Клиент может: • выравнивать размеры пакетов, • добавлять шум, • менять тайминги, • смешивать типы запросов, • имитировать профиль обычного мобильного приложения. Это снижает точность детекта, хотя и увеличивает накладные расходы. 7. Использование массовых облаков и распределенной edge-инфраструктуры. Чем ближе и распределеннее точки входа, тем тяжелее их глушить “по площадям”. Особенно если они растворены среди огромного количества другого трафика. Но тут вечная проблема: если регулятор готов жертвовать качеством интернета, то и такие вещи режутся грубо.

Сейчас бы пользоваться российскими почтами)))