Жизнь диссидента-экспериментатора не сидит на месте, а копилка безумных находок пополняется быстрее, чем успеваешь про них написать. Продолжаем то, на чем остановились в прошлый раз - туннели через ICMP, DNS и serverless-функции это, конечно, хорошо, но вот вам еще три свежие находки: туннель через что угодно, что умеет хранить файлы, туннель через почтовый ящик, и реанимация древней технологии обхода через CDN и не только, которую почему-то все забыли.

XTLS-Reality, XHTTP, Naiveproxy и всякие там AnyTLS - это не интересно. Давайте копнем чуть глубже и посмотрим, где прячется настоящее безумие. Особенно учитывая, что мы живем во времена, когда даже самые, казалось бы, безумные вещи, могут оказаться весьма полезными чтобы не сойти с ума.

Пользователи профильного NTC‑форума (открывается только через IPv6), посвященного исследованиям интернет‑цензуры и обхода блокировок, обнаружили необычное сетевое поведение российского мессенджера MAX. Речь про официальный APK с официального сайта.

Схема была довольно прямолинейной: в одном случае использовали PCAPdroid — приложение, которое на Android‑устройстве имитирует VPN для перехвата сетевого трафика без необходимости получения root‑прав, таким образом позволяя отслеживать, анализировать и блокировать сетевые соединения, осуществляемые приложениями на устройстве. В другом случае анализировался трафик из эмулятора, причем отдельно отмечено, что образ системы в эмуляторе был «чистый», без установленных других мессенджеров и дополнительного софта.

По наблюдениям (дампы PCAPdroid выложены на форуме), мессенджер MAX регулярно дергает сразу несколько сервисов для определения внешнего IP‑адреса, причём часть из них — зарубежные. Среди доменов, которые всплыли при проверке, кроме российских сервисов, видны также иностранные сервисы.

Три года назад я написал статью “Интернет-цензура и обход блокировок: не время расслабляться”. Перечитывая ее сейчас, спустя три года, не могу избавиться от двоякого чувства: с одной стороны я почти во всем оказался прав касательно того, как будут развиваться события, усиливаться блокировки, и регулироваться законодательство. С другой стороны, кое в чем я тогда серьезно ошибся.

А именно: слишком уж я надеялся на то, что доблестные фильтраторы интернета будут заботиться об уменьшении побочных эффектов и так называемого collateral damage, и поэтому будут вынуждены изобретать более сложные технологии детектирования, продолжая увлекательную игру в кошки-мышки. Реальность же оказалась гораздо прозаичнее: зачем думать, когда в руке кувалда? В результате чего имеем следующее: часть детектирования откровенно тупая (например, блок нескольких параллельных подключений к одному IP, что решается использованием gRPC-транспорта для VLESS или XHTTP-транспорта с правильными настройками мультиплексирования), а часть - еще тупее, а именно, никакого детектирования, а тупо бан популярных хостеров и облачных провайдеров целыми подсетями /16 и даже /8 - в результате чего или нельзя подключиться по TLS вообще, или можно, но соединение фризится после передачи примерно 16 килобайт данных, или же блок срабатывает на целую подсеть после случайного обращения к какому-нибудь “плохому” IP-адресу. За анализ огромное спасибо товарищу @0ka и его статьям “РКН создали белый список для 72 AS, но пострадали 391 AS (>225 млн IP адресов)”  и “РКН создали список подозрительных айпи адресов (динамическая блокировка 47 AS)”.