Интернет-цензура и обход блокировок: не время расслабляться

[admin]

Disclaimer: практически всё, описанное в статье, не является чем-то принципиально новым или инновационным - оно давно известно и придумано, используется в разных странах мира, реализовано в коде и описано в научных и технических публикациях, поэтому никакого ящика Пандоры я не открываю.
Нередко на Хабре в темах, посвященных блокировкам ресурсов, встречаются забавные заявления вида "Я настроил TLS-VPN, теперь будут смотреть что хочу и цензоры мой VPN не заблокируют", "Я использую SSH-туннель, значит все ок, не забанят же они весь SSH целиком", и подобное. Что ж, давайте проанализируем опыт других стран и подумаем, как же оно может быть на самом деле.
0

Итак, допустим мы купили у какого-то сервиса, или, как подкованные пользователи, установили в личном облаке/VPS и настроили VPN-сервер для себя. Допустим, это популярные WireGuard или OpenVPN. Знаете что? WireGuard - это такой прекрасный протокол, который всеми своими пакетами просто кричит "Смотрите все, смотрите, я - VPN". И это, в принципе, не удивительно, потому что авторы на сайте проекта прямым текстом пишут, что обфускация не входила и не будет входить в их цели и планы.
Соответственно, на оборудовании DPI (оно же ТСПУ) при небольшом желании протокол WireGuard выявляется и блокируется на раз-два. IPSec/L2TP - аналогично. С OpenVPN то же самое - это, наверное, вообще самый первый протокол, который китайцы научились выявлять и банить на своем "великом китайском фаерволе" (GFW). We are fucked.
1

Окей, допустим мы сделали выводы, и вместо совсем уж палевных протоколов решили использовать TLS-VPN, такие как SSTP, AnyConnect/OpenConnect или SoftEther - трафик в них ходит внутри TLS, начальная установка соединения производится по HTTP - что должно быть совсем никак неотличимо от обычного подключения к любому обычному сайту. Ну, как сказать...
В случае с MS SSTP цензоры, желая выяснить, а чем же вы таким занимаетесь, просто сделают запрос на ваш сервер с URL /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ c HTTP-методом SSTP_DUPLEX_POST, как это описано Для просмотра ссылки Войди или Зарегистрируйся, и сервер радостно подтвердит в ответ, что он - да, действительно MS SSTP VPN.
SoftetherVPN в ответ на GET-запрос с путем /vpnsvc/connect.cgi, типом application/octet-stream и пэйлоадом 'VPNCONNECT' выдаст в ответ 200 код и предсказуемый бинарный блоб с рассказом о том, кто он такой.
AnyConnect/OpenConnect при обращении по / или по /auth ответят очень характерной XML'кой. И от всего этого вы не избавитесь никак - это определено в протоколах, и именно через эту логику работают VPN-клиенты. We are fucked.
2

Ясно, мы будем умнее, и поскольку у нас все-таки TLS, давайте поставим перед VPN-сервером reverse-прокси (например, haproxy) и будем разруливать всё по SNI (server name identification): подключения с определенным доменом в запросе будем отправлять на VPN-сервер, а все остальные - на безобидный сайт с котиками. Можно даже попробовать спрятаться за какой-нибудь CDN - не забанят же они весь CDN, правда, и наш трафик из общего трафика ко всей CDN выцепить не смогут, да?
Правда, есть одно "но". В нынешних версиях TLS поле SNI не шифруется, соответственно цензоры легко его подсмотрят и сделают запрос именно с тем именем домена, что надо. На расширение Encrypted Client Hello (ECH), ранее известное как eSNI, можно не рассчитывать: во-первых, оно находится еще Для просмотра ссылки Войди или Зарегистрируйся и неизвестно когда будет принято и повсеместно использоваться, а во-вторых, цензоры могут взять и просто-напросто заблокировать все соединения TLSv1.3 с ECH, Для просмотра ссылки Войди или Зарегистрируйся. Проблемы индейцев шерифа не волнуют. We are fucked.
3

Шутки в стороны, мы настроены решительно. Например, мы пропатчили OpenConnect-сервер, чтобы он принимал подключения только со специальным словом в URL'е (благо, AnyConnect/OpenConnect-клиенты такое позволяют), а всем остальным отдавал правдоподобную заглушку. Или настроили обязательную аутентификацию по клиентским сертификатам.
Или же мы подключаем тяжелую артиллерию от товарищей-китайцев, которые на обходе блокировок собаку съели - V2Ray/Для просмотра ссылки Войди или Зарегистрируйся с плагином VMess и VLess поверх Websockets или gRPC, либо Для просмотра ссылки Войди или Зарегистрируйся. Они работают поверх TLS, могут делить один и тот же порт с HTTPS-вебсервером, и не зная заветной секретной строчки, которую подслушать снаружи не получится, выявить наличие туннеля и подключиться к нему, казалось бы нельзя, значит все хорошо?
Давайте подумаем. Каждый TLS-клиент при подключении передает серверу определенный набор параметров: поддерживаемые версии TLS, поддерживаемые наборы шифров, поддерживаемые расширения, эллиптические кривые и их форматы. У каждой библиотеки этот набор свой, и его варианты можно анализировать. Это называется Для просмотра ссылки Войди или Зарегистрируйся. Отпечаток (fingerprint) библиотеки OpenSSL отличается от отпечатка библиотеки GnuTLS. Отпечаток TLS-библиотеки языка Go отличается от fingerprint'а браузера Firefox.
И когда с вашего адреса будут зафиксированы частые и долгие подключения к некому сайту клиентом с библиотекой GnuTLS (которая не используется ни в одном популярном браузере, но используется в VPN-клиенте OpenConnect), или с мобильного телефона через мобильного оператора подключается какой-то клиент на Go (на котором написан V2Ray), we are fucked. Такое детектирование, например, производится Для просмотра ссылки Войди или Зарегистрируйся и Для просмотра ссылки Войди или Зарегистрируйся.
4

Ладно. Допустим, мы пересобрали наш V2Ray-клиент не со стандартной TLS-либой, а с Для просмотра ссылки Войди или Зарегистрируйся, которая может маскироваться под популярные браузеры. Или вообщеДля просмотра ссылки Войди или Зарегистрируйся, чтобы быть совсем уже неотличимыми от обычного браузерного TLS. Или решили пойти в сторону маскировки под другие протоколы типа SSH, или взяли Для просмотра ссылки Войди или Зарегистрируйся. Или какой-нибудь KCP/Для просмотра ссылки Войди или Зарегистрируйся с маскировкой под DTLS.
Короче говоря, допустим у нас что-то более редкое и незаметное. Казалось бы, все хорошо? Ну как сказать. Помните "пакет Яровой"? Тот самый, который требует, чтобы интернет-сервисы сохраняли все метаданные сессий, а интернет-провайдеры так вообще записывали дампы трафика своих абонентов? Многие, еще тогда смеялись - мол, ну тупые, что им дадут гигабайты зашифрованных данных, которые они все равно не расшифруют? А вот что.
Пользуетесь вы, допустим, своим туннельчиком, смотрите всякие там запрещенные сайты. А потом - клик! - и случайно заходите через свой туннель на какой-нибудь отечественный сайт или сервис, замеченный в сотрудничестве с государством - условные там VK/Mail.ru/Яндекс или еще что-нибудь. Или на каком-нибудь безобидном сайте попадается виджет, баннер или счетчик от них же. Или кто-нибудь в комментарии вбросит ссылку на какой-нибудь сайт-honeypot, косящий под новостной ресурс, и вы на нее нажмете.
И вот тут произойдет самое интересное. Что внутри TLS, что внутри SSH, что внутри OpenVPN+xor, данные передаются в зашифрованном виде, и их не расшифровать. Но вот "внешняя форма" (размеры пакетов и тайминги между ними) у зашифрованных данных точно такая же, как и у нешифрованных. Цензоры видят, что от абонента к какому-то неизвестному серверу и обратно ходит трафик, а поток со стороны какого-нибудь подконтрольного сервиса видит, что с того же IP-адреса, что у "неизвестного сервера", туда прилетают какие-то запросы и улетают ответы, и - вот интересно - размеры пакетов и временные моменты практически полностью совпадают. Что весьма характерно говорит о том, что у нас тут прокси, возможно VPN, Андрюха, по коням!
И да, если вы поступите мудрее и у вашего сервера будет два IP-адреса, один на вход, а другой на выход, то сопоставить ваш "вход" и "выход" по адресам не получится, но по "форме" переданных данных, хоть и ощутимо сложнее, но при желании по прежнему можно. We are fucked again.
5

Не так уж плохо дело. Мы настроили для своего туннеля rule-based access. А именно, будем ходить по нему только туда, куда надо, и тогда, когда надо - а во всех остальных случаях пусть пакетики бегают сразу по обычному интернет-подключению. Правда, добавлять каждый раз новый ресурс в список - тот еще геморрой, особенно когда вы держите прокси/VPN не только для себя, но и, например, для далеко живущих немолодых родителей, которые, например, хотят читать всяких там иноагентов - но это, на самом деле, мелочи, мы справимся.
Допустим, мы по-прежнему используем SSH-туннель. Правда, проработает он, скорее всего, недолго. Почему? Потому что дело во всех тех же паттернах трафика. И нет, записывать и мучительно сравнивать ничего никуда уже не надо. Паттерны трафика у ssh-as-console, ssh-as-ftp и ssh-as-proxy очень разные и элементарно выявляются довольно просто должным образом натренированной нейросетью. Поэтому китайцы и Для просмотра ссылки Войди или Зарегистрируйся уже давно всё подобное "неправильное" использование SSH выявляют и режут скорость подключения до черепашьей, что в терминале работать вы еще сможете, а вот серфить - практически нет.
Ну или, допустим, вы все-таки используете whatever-over-TLS-туннель с учетом всего приведенного в этой статье. Но проблема в том, что все сказанное в предыдущем абзаце, применимо и к нему - а именно, TLS-inside-TLS Для просмотра ссылки Войди или Зарегистрируйся с помощью эвристик и машинного обучения, которое еще можно дополнительно натренировать на наиболее популярных сайтах. We are still fucked.
6

Ладно. Мы добавили в наш тайный туннель random padding - "дописывание" в конец пакета какого-нибудь мусора случайно длины, чтобы сбить с толку наблюдателей. Или специально бьём пакеты на маленькие кусочки (и получаем проблемы с MTU, ой, придется потом старательно пересобирать). Или, наоборот, когда у нас внутри туннеля устанавливается TLS-соединение с каким-нибудь сервером, мы Для просмотра ссылки Войди или Зарегистрируйся, таким образом выглядя со стороны на сто процентов как обычный TLS без двойного дна (правда, придется еще потратить несколько итераций на доведение протокола до ума и Для просмотра ссылки Войди или Зарегистрируйся). Казалось бы, happy end, we are not fucked anymore?
А тут начинается все самое интересное. А именно, рано или поздно в вопросах выявления туннелей и блокировок, особенно с развитием технологий их обхода (в конце концов, мы ещё не затронули стеганографию и много других интересных вещей), начинает расти то, что называется collateral damage - ущерб, возникший случайно в ходе атаки намеренной цели. Например, как говорят инсайдеры и подтверждают сводки с полей, то самое упомянутое выше выявление tls-inside-tls даже с random padding'ом китайцы научились выявлять примерно с Для просмотра ссылки Войди или Зарегистрируйся. Понятно дело, что при такой точности возможны также ложные срабатывания, но когда проблемы индейцев волновали шерифа?
Протоколы, которые снаружи не похожи ни на что (например, shadowsocks, obfs4, и т.д.) тоже при большом желании можно выявить по... Для просмотра ссылки Войди или Зарегистрируйся, потому что у зашифрованного трафика это соотношение очень близко к 1:1 - хотя, понятное дело, при этом могут пострадать невиновные. Можно банить адреса, когда висят слишком много или слишком долго подключения к не-являющимися-очень-популярными-сайтам. Подобных вариантов довольно много, и если вы думаете, что цензоров остановят ложноположительные срабатывания и ущерб от блокировок добропорядочных сайтов - то вы заблуждаетесь.
Когда Роскомнадзор пытался заблокировать Telegram, они вносили в бан-лист целые подсети и хостинги, таким образомДля просмотра ссылки Войди или Зарегистрируйся - и им за это ничего не было. В Иране, в связи с популярностью упомянутого выше похожего-на-браузер-прокси-клиента, цензоры Для просмотра ссылки Войди или Зарегистрируйся с Chrome TLS fingerprint к популярным облачным сервисам. В КитаеДля просмотра ссылки Войди или Зарегистрируйся, услугами которых пользуются безобидные и невиновные сайты и сервисы. В Туркменистане так вообще Для просмотра ссылки Войди или Зарегистрируйся, потому что стоит цензорам только выявить хотя бы один VPN или прокси, как в бан отправляется целый диапазон адресов около него или даже вся AS.
Вы, наверное, можете спросить, а что же делать юрлицам, которые тоже пользуются VPN для работы, или чьи сервисы могут случайно попасть под раздачу? Этот вопрос легко решается белыми списками: если юрлицу нужен VPN-сервер, или нужно обезопасить от случайной блокировки какие-либо свои сервисы, то стоит обязать их заранее сообщать о нужных адресах и протоколах в соответствующие ведомства, чтобы те добавили их в какой надо список - именно такие запросы Роскомнадзор через ЦБ Для просмотра ссылки Войди или Зарегистрируйся, задумывая что-то нехорошее, и механизм таких списков Для просмотра ссылки Войди или Зарегистрируйся.
Ну и, естественно, вполне вытекающим продолжением из этого будет "все что не разрешено - то запрещено". Для просмотра ссылки Войди или Зарегистрируйся в РФ уже есть. Запрет использования несертифицированных средств шифрования - Для просмотра ссылки Войди или Зарегистрируйся. Подкрутить и расширить их зоны применения и многократно ужесточить наказания за такие "нарушения" - дело несложное. В Китае вежливые ребята пришли в гости к разработчикам небезизвестных ShadowSocks и GoAgent и Для просмотра ссылки Войди или Зарегистрируйся. В Иране Для просмотра ссылки Войди или Зарегистрируйся в связи с использованием VPN для доступа к запрещенным сайтам. Механизм стукачества в органы на неблагонадежных соседей был отлично отработан еще в прошлом веке в СССР. У государств есть монополия на насилие, не забывайте. We are fucked again?
4294967295

К чему это всё?
Как я уже сказал, большая часть того, что описано в статье, не является выдумками или голой теорией - оно давно известно, используется в некоторых странах мира, реализовано в коде и даже описано в научных публикациях.
Обход блокировок - это постоянная борьба щита и меча, и одновременно игра в кошки-мышки: иногда ты ешь медведя, иногда медведь ест тебя иногда ты догоняющий, иногда догоняемый.
Если у вас сейчас есть прокси или VPN, и он работает - не расслабляйтесь: вы всего-лишь на полшага впереди недоброжелателей. Можно, конечно, спокойно сидеть и думать "Да они там все дураки и криворукие обезьяны и ниасилят ничего сложного и реально работающего", но, как говорится, надейся на лучшее, а готовься к худшему. Всегда есть смысл изучить опыт тех же китайских коллег и присмотреться к более сложновыявляемым и более цензуроустойчивым разработкам. На чем больше шагов вы будете впереди цензоров, тем больше времени у вас будет в запасе чтобы адаптироваться к изменившейся ситуации. Если вы разработчик и разбираетесь в сетевых протоколах и технологиях - можно присоединиться к одному из существующих проектов, помочь с разработкой и подумать над новыми идеями. Люди всего мира скажут вам спасибо.
Интересными и полезными в этом плане будут Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся (там большая часть на китайском, но автопереводчик на английский справляется неплохо), Для просмотра ссылки Войди или Зарегистрируйся. Если кто-то знает ещё хорошие ресурсы и сообщества по этой теме - напишите в комментарии
Ну и не стоит забывать, что рано или поздно, не имея возможности противостоять подобному свободолюбию технически, государство может начать противостоять административно (та самая монополия на насилие), причем так, что с вашей стороны, в свою очередь, технически противостоять может уже не получиться. Но это уже совсем другая история, требующая отдельной статьи, и, скорее всего, на другом ресурсе.
Когда я писал эту публикацию, я хотел вставить в нее картинки из какого-нибудь мрачного киберпанк-фильма, где в результате развития технологиий слежения и цензуры и невозможности противостоять этому, люди целиком и полностью стали подконтрольны государствам и потеряли все права на свободу мысли и приватность личной жизни. Но я надеюсь, до этого не дойдет. Все в наших руках.


source: habr.com/ru/post/710980/