Domain fronting: как работал обход SNI-фильтрации и почему умер

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.

Апрель 2018-го. Роскомнадзор второй месяц пытается заблокировать Telegram, Telegram огрызается, перекидывая инфраструктуру на облака Google и Amazon. Роскомнадзор в ответ банит уже не сам Telegram, а целые подсети - 18 штук плюс россыпь отдельных адресов - принадлежащих Google и Amazon. Через несколько дней куски рунета, вообще не имеющие отношения к Telegram, начинают отваливаться: у кого-то ломается авторизация через сторонние сервисы, у кого-то - платёжные виджеты, у кого-то просто резко потухли облачные бэкенды.

А ещё через пару недель сам Google, а следом и Amazon, закрывают лазейку, на которой всё это держалось - и Telegram тут не единственная причина, был повод пожёстче. Технология называлась domain fronting, и это тот редкий случай, когда история интереснее самого механизма.

Кому пригодится: если любите разбираться, как на самом деле устроены обходные технологии, а не просто пользоваться готовым; если интересна история блокировок рунета; или если просто хочется понять термин, который то и дело всплывает в старых статьях про Tor и Signal.

Статья историческая. Технология не работает уже который год, ниже - разбор того, как это было устроено и почему заглохло, а не рабочий гайд. Обычно я пишу что-то более полезное, но тут скорее дискавери включили в 3 часа ночи и там что-то такое рассказывают

Содержание

Сначала - что вообще такое SNI
Сама идея domain fronting
Почему это вообще работало
Кто этим пользовался
Российский эпизод: Telegram и бан половины Google с Amazon
Апрель 2018: как Google и Amazon всё закрыли
Почему это не работает сейчас
ECH: похожая цель, другой путь
Короткий итог

Источники

Сначала - что вообще такое SNI

Без этого дальше будет непонятно, откуда вообще растёт вся история.

Когда браузер стучится на HTTPS-сайт, до того как соединение зашифруется, происходит рукопожатие TLS. И на одном IP-адресе сегодня почти всегда висит не один сайт, а сотни - серверу нужно заранее знать, какой именно сертификат показывать клиенту. Для этого клиент в самом начале рукопожатия, ещё открытым текстом, называет домен, к которому идёт - это поле и есть SNI (Server Name Indication).

Отсюда и самый простой способ цензуры: не нужно разбирать зашифрованный трафик, достаточно читать одно это поле. Увидел в SNI запрещённый домен - оборвал соединение. Дёшево и почти всегда работает, потому что до появления шифрования самого SNI (об этом ниже, в разделе про ECH) поле реально шло в открытую, его видел кто угодно на пути пакета.

Сама идея domain fronting

А теперь фокус. TLS-рукопожатие с открытым SNI - только первый шаг. Дальше, уже внутри зашифрованного соединения, браузер отправляет обычный HTTP-запрос, и там тоже есть поле с именем домена - заголовок Host. По-хорошему оба поля, SNI и Host, должны совпадать. Но правило это не техническое, а просто вежливость - и до 2018 года крупные CDN вроде Google и Amazon его не проверяли.

Отсюда и трюк: в SNI пишем один домен - безобидный, крупный, который цензор точно не станет блокировать (скажем, какой-нибудь известный поддомен самого Google). А в зашифрованном Host-заголовке, который цензор физически не видит, - настоящий адрес, тот самый заблокированный сервис. Цензор смотрит на SNI, видит «Google», пожимает плечами и пропускает пакет. А CDN на своей стороне читает уже Host и честно отдаёт контент того сервиса, который там реально указан.

Название говорит само за себя: вы «фронтите» - прикрываетесь спереди - чужим, приличным доменом, хотя едете совсем в другое место.

Аналогия, чтобы прям на пальцах. Представьте посылку с двумя адресами: снаружи на коробке - адрес крупного, уважаемого склада, который таможня пропускает не глядя. А внутри, в сопроводительном листе, который таможня не вскрывает - настоящий адрес получателя. Курьерская служба свою же коробку доставляет туда, куда сказано внутри, а не туда, что написано снаружи.

Почему это вообще работало

Ключевое условие - у обоих доменов, фронтового и настоящего, должен быть один и тот же провайдер, который обслуживает тысячи разных клиентов на общем пуле IP-адресов и внутри себя маршрутизирует именно по Host, а не по SNI. Google App Engine, Amazon CloudFront, одно время Fastly, Azure - у всех крупных облаков за один IP пряталось множество совершенно разных сайтов и сервисов.

Если ваш сервис уже был клиентом такого облака (или мог арендовать там хотя бы дешёвый инстанс), вы получали право «прятаться» за любым другим доменом этого же облака - хоть за самим google.com. Заблокировать такой фронт для цензора означало заблокировать вообще весь диапазон крупного облачного провайдера - а это уже задевает половину интернета, а не одного нарушителя.

Кто этим пользовался

Список получился не маленький - около десятка технологий, так или иначе завязанных на приватность и обход блокировок:

Tor - плагин meek, один из pluggable transports, фронтил через Google App Engine, а после его закрытия переехал на Amazon CloudFront.
Signal - прятал трафик за доменами Google, а когда Google прикрыл лавочку, на короткое время перебрался на амазоновский souq.com (крупнейший на тот момент интернет-магазин на Ближнем Востоке, тоже хостившийся на AWS) - в отчаянной попытке продержаться ещё немного.
Psiphon, Lantern, исследовательский проект Telex, площадка GreatFire.org - все в разное время строились на той же идее.
И, как отдельная и самая заметная в рунете история - Telegram весной 2018-го, о ней ниже подробно.

Российский эпизод: Telegram и бан половины Google с Amazon

13 апреля 2018 года суд обязал заблокировать Telegram в России - после того как мессенджер отказался передавать ФСБ ключи шифрования. Telegram эту блокировку попросту игнорировал технически: перекинул часть инфраструктуры на Google Cloud и AWS, пользуясь ровно той же логикой domain fronting, чтобы прятаться за чужими, незаблокированными доменами этих облаков.

Роскомнадзор ответил тяжёлой артиллерией. Глава ведомства Александр Жаров заявил о блокировке 18 подсетей и ещё россыпи отдельных IP-адресов, принадлежащих Google и Amazon - вместо точечного бана самого Telegram под нож попала облачная инфраструктура целыми кусками. Дальше - предсказуемо: под раздачу попадал любой сторонний сервис в России, который просто имел неосторожность работать через те же облака, Telegram тут был лишь поводом. Обвал был настолько заметным, что об этом писали далеко за пределами рунета.

Сам Telegram, к слову, заблокировать так толком и не вышло - он попросту перескакивал на новые адреса быстрее, чем Роскомнадзор успевал их банить.

Апрель 2018: как Google и Amazon всё закрыли

И вот тут по времени всё сходится почти день в день. В середине апреля 2018-го Google отключает domain fronting у себя. Amazon следует буквально через пару недель, в конце апреля - начале мая.

Официальная причина шире, чем просто Telegram или цензура в целом, хотя коллатеральный ущерб от истории с Россией точно не добавил доверия к технологии. Основной публично называемый повод жёстче: domain fronting активно использовали и для откровенно вредоносных целей. Самый громкий пример - группировка APT29, которую связывают с российской разведкой (ФСБ), использовала эту же технику для скрытной связи вредоносного ПО со своими командными серверами. Получилась своеобразная историческая ирония: тот же приём, что помогал Telegram уворачиваться от блокировки внутри России, использовался (по независимым от этой истории данным) структурами, близкими к российским спецслужбам, для вредоносной инфраструктуры - и именно совокупность такого злоупотребления в итоге и закрыла лавочку для всех разом, включая инструменты правозащитной направленности вроде Signal и Tor.

Технически закрыли просто: обе площадки перестали слепо доверять Host-заголовку и начали сверять его с тем, что было в SNI на этапе рукопожатия. Не совпадает - соединение рвётся. Без этого совпадения весь фокус с «фронтом» рассыпался мгновенно.

Почему это не работает сейчас

С 2018 года ничего принципиально не изменилось - крупные облака как проверяли соответствие SNI и Host, так и проверяют. Технология не «стала сложнее», она просто перестала быть возможной архитектурно на всех сколько-нибудь крупных площадках. Изредка встречаются рассказы про мелкие или неправильно настроенные CDN, где по случайности такое всё ещё проходит - но это не рабочая стратегия, а разовая случайность, которая закроется при первом же обновлении конфигурации провайдера.

Если где-то в старой статье встретите domain fronting как актуальный совет - смело считайте это историческим анахронизмом, а не рабочим рецептом.

ECH: похожая цель, другой путь

У современных протоколов есть свой ответ на ту же исходную проблему - «цензор читает SNI открытым текстом» - но решает её принципиально иначе. Encrypted Client Hello (ECH) не пытается обмануть цензора чужим именем, а просто шифрует само поле SNI целиком, так что снаружи его вообще не видно - ни настоящего домена, ни поддельного.

Механизм там совсем другой: сервер заранее публикует в DNS специальный публичный ключ (через записи HTTPS/SVCB), клиент на этом ключе шифрует настоящее имя домена перед отправкой. Технология молодая, местами сама уже становится мишенью отдельной блокировки в некоторых странах, и это уже тема для отдельного разговора. Тут коротко: идейно ECH ближе всего к тому, что когда-то пытался решить domain fronting, просто более честным и устойчивым способом.

Короткий итог

Domain fronting играл на разнице между двумя полями: открытым SNI (там - безобидный домен) и зашифрованным Host-заголовком (там - настоящий адрес), пока крупные CDN не сверяли одно с другим.
Работало это только пока фронтовый и настоящий домен сидели на одном облаке с общим пулом IP - Google App Engine, Amazon CloudFront и подобные.
Технологией пользовались Tor (meek), Signal, Psiphon, Lantern и другие - и Telegram весной 2018-го при попытке обойти блокировку в России.
Попытка Роскомнадзора забанить Telegram через блокировку подсетей Google и Amazon зацепила половину несвязанных сервисов рунета коллатералом.
В апреле-мае 2018-го Google и Amazon закрыли лазейку - официально из-за злоупотреблений вроде вредоносной инфраструктуры APT29, цензурный контекст был не единственной причиной.
С тех пор технология не работает на любой сколько-нибудь крупной площадке - это история, а не рабочий метод.

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.