Комментарии 46
В новостях российских СМИ по этому поводу можно было видеть много примеров того, как "ученый изнасиловал журналиста".
От "гугл/амазон запретили использовать свой сервис для обхода блокировок Роскомнадзора" до "амазон запретил использование прокси-серверов".
Так что всегда лучше читать оригинал.
Domain fronting это использование CDN в качестве HTTP-прокси.
CDN по сути и есть обратный кеширующий прокси. Другое дело что конечный сервер к которому CDN подключается тоже может работать как прокси давая доступ уже ко всему интернету.
А в случае когда прикрытие домена используется просто для доступа к обычному сайту в этой сети то разницы для CDN не должно быть.
Стоит добавить что в браузере прикрытие доменом реализуется простым proxy.pac только если сайт форсированно не переводит на https.
function FindProxyForURL(url, host)
{
if (host == "[заблокированный домен]" && shExpMatch(url, "http:*"))
return "HTTPS [не блокируемый домен];";
else
return "DIRECT";
}Алгоритм действий такой.
- Заходим на sslchecker
- Вводим заблокированный домен
- В поле SAN выбираем рабочий не заблокированный домен
- Проверяем выбранный домен(должен открываться по https)
- Подставляем домены в proxy.pac скрипт соответственно
Данный скрипт сработает для адреса http://[заблокированный домен]
Возможно данный метод будет работать и для сайтов у которых нет https вообще. Надо найти сайт на том-же IP у которого будет https и им прикрыть.
Уже сама формулировка "сайт без https" в наше время вызывает вопросы. Let's Encrypt опять же.
Ну почему то bittorrent.org не озаботились сертификатом для сайта. Но с этим сайтом этот метод не работает.
Отдельные лучи света всяким фильмам, видосам и поклонникам BD рипов.
В общем много много тон угля сгорает что бы защитить порнуху.
Современные и даже уже устаревшие процессоры легко делают AES со скоростью больше гигабайта в секунду, о каких тоннах угля вы говорите? Десять-пятнадцать лет назад шифрование может быть и было проблемой, но в наше время затраты на шифрования ничтожны по сравнению с преимуществами в части безопасности и конфиденциальности, которые оно даёт.
Впрочем производители железа потирают руки, как и производители OC
Не Телеграм, а Signal. И даже не Signal, а хакеры из группы APT29. До того как эти личности начали для своих тёмных делишек использовать эту возможность, никому не было дела до того что Signal использует google.com для обхода цензуры. В статье даже написано что Signal пользовался этим приёмом больше года. Всё это время его приёмы никому не мешали.
На сами по себе разборки РКН-Телеграм им плевать. я думаю. Бизнес защищает только свои инвестиции.
Об этом стало известно 13 апреля, следовательно, решение внутри корпорации было принято ещё раньше.
К тому же, говорят, что domain fronting для Google AppEngine не использовался Телеграмом вообще.
К сожалению, в tls1.3 имя в sni осталось нешифрованным. Я тоже сначала понадеялся, что пришло тотальное шифрование, но нет — Wireshark видит имя сайта, на котором Chrome показывает TLS 1.3 :(
Тем не менее стандарт разрабатывается: SNI Encryption in TLS Through Tunneling.
И есть два решения:
- Tunneling TLS in TLS
Который работает аналогично прикрытию домена только на втором этапе создаётся уже шифрованный канал к целевому серверу. Для первой части могут быть использованы сертификаты выданные на IP а не домен. Новые соеденения с сервером уже могут быть установленны используя 0-RTT который вроде как открытого SNI уже не требует. - SNI encryption with combined tickets
Этот вариант я пока не разобрал.
На IP также выдаются сертификаты и их тоже можно проверить. После этого внутри тунеля установленного по IP можно установить соединение по домену.
На IP также выдаются сертификаты и их тоже можно проверить.
А ещё некоторые считают, что если скаченный с рандомного сайта софт имеет валидный сертификат (с именем "Vasya Pupkin Ltd") — то он точно без вирусов.
После этого внутри тунеля установленного по IP можно установить соединение по домену.
А давайте ещё весь TOR-протокол в TLS засунем — чтобы никто не знал, кто с кем соединяется. У TLS другое назначение — давать каналу связи криптографическую защиту от прослушивания/подделки. Скрывать тот факт, что две известные стороны соединились друг с другом, там не планировалось — это никак не помогает его целям, но становится вообще бесполезным, когда вас и вашего партнёра просто вычислят по ай-пи (далеко не у всех сайтов ай-пи принадлежит безымянному общему cdn, ну а про клиентов и говорить нечего). Всякие прокси-подобные механизмы мутного назначения, очевидно, существуют, но в спецификации протокола поточного шифрования им не место.
Возникает законный вопрос: если Google и Amazon не хотят помогать обходить цензуру, то означает ли что они прислуживают всемирному злу? На этот ответ нельзя дать однозначный ответ, так как есть факты использования доменного прикрытия не только для обхода цензуры, но и для несанкционированного удалённого доступа при взломах.
Тут употреблено правильное выражение: "не хотят помогать". Речь тут идёт действительно именно в категориях "помогать/не помогать", а не "не мешать/мешать" (видите разницу?), как некоторые это воспринимают и обижаются. Пулы айпи-адресов стоят довольно много денег, эти деньги на них потратил условный амазон, а вы теперь хотите, чтобы вам за просто так дали ими пользоваться. Клиенты, которые на этих пулах сидят (и, местами, прикрывают их от блокировок), стоят ещё больше денег, и амазон, опять же, вложил много своих средств ради привлечения этих клиентов. А кто-то вдруг хочет всем этим (большим пулом адресов, из которых можно выбирать, и соседством с важными клиентами. которых не будут блокировать) воспользоваться по сути забесплатно (по цене одной виртуалки или что там надо заказать чтобы тебе дали адрес). Нет, выгоду от своих вложений амазон вполне логично забирает себе, а клиенту с одной виртуалкой дают только то, что он заказал. И от соседей максимально огораживают, чтобы он не эксплуатировал соседство с ними, которое в цену услуги, естественно, не входит.
Приложения такое, в целом, и без публичных CDN могут использовать: делать запрос на свой сервер, указывать в SNI хост google.com, а внутри шифрованного канала (да хоть бы и с самоподписанным сертификатом для google.com — вряд ли законотворцы обяжут все сайты подписываться только одобренными доверенными CA) передавать всё, что угодно — это ведь Гуглом не запрещается, ибо их CDN не задействован? Или я что-то упустил?
Нет, не упустили. Эта идея действительно сработает если цензор не будет присматриваться к деталям, а это будет если ваше приложение (а мы говорим об обходе цензуры для приложений), не будет представлять сколько-нибудь особого интереса. Телеграм явно не такое приложение никому не интересное приложение. Потому такую идею будет сложно применить на практике для сколько-нибудь популярных приложений.
Ну, а в текущих реалиях, когда Телеграм меняет IP-адреса, как перчатки — РКН сможет ли с таким что-либо сделать, кроме продолжения выкашивания огромных подсетей? =)
Телеграм не просто может менять IP адреса, а может и выдавать разным людям — разные IP адреса. Значит цензура просто не сможет знать все IP адреса, которыми пользуется Телеграм, подглядывая за работой официального клиента. Даже блокировкой подсетей от этого не защититься: ведь как заблокировать то, не знаешь что?..
Значит тут остаётся только вариант прессовать провайдеров облачных услуг чтобы те выгнали Телеграм со своих мощностей, что и происходит. РКН сейчас как такие гопники-рэкетиры пытаются сыграть с Телеграмом ещё раз ту карту, с которой у них получилось раньше с Zello, без стеснения заявляя что символично блокируют ровно половину IP адресов AWS. Правда, учитывая незначительность российского рынка для облачных компаний, важность облачных сервисов для российских организаций, и политический накал ситуации (Жаров находится под санкциями), в этот раз трюк пока не работает так, как в прошлый раз.
Простите ради бога, но если бы подобная статья была совсем для совсем далёких от IT читателей, которые ни одной идеи о работе HTTP не имеют, то какое место такой статье было бы на Хабре, который позиционирует себя как крупнейший в Европе ресурс для IT-специалистов? У нас тут технически подкованная аудитория, которую не удивишь RFC 2616. На Хабре да на пальцах рассказывать про заголовок Host — всё равно что своих читателей не уважать.
То есть, надо иметь в виду приблизительный портрет читателя. Например, человек прочитал журналистскую новость «вот, раньше для объода блокировки через Гугль работало, а теперь не работают, они объясняют это косяком с настройками и случайностью, а не фичей». Человек из такого объяснения ессно нифига не понимает, и (если он немножко технарь и интересуется) начинает искать, а что же это такое. Положим, он хотя бы раз набирал в telnet
GET / HTTP/1.1
Host: site.comи в курсе, скажем, про виртуальные хосты на ОДНОМ сервере (например, видел конфиги Апача когда-то давно). Соответственно, для такого человека, Ваши примеры с подстановкой разных Host: с одной стороны, самоочевидны — ведь в самой исходной постановке вопроса и шла речь, что при запросе на один адрес выдается какой-то другой. С другой стороны, подстановки в примерах про habr.ru и habrahabr.ru выглядят для него столь же надуманными, как попытки в первый раз объяснить рекурсию факториалом, а не Фибоначчи (будет резонный встречный вопрос про неудачность примера «а зачем, ведь цикл же проще»). То есть, не объясняется, а почему именно эти, причем тут конкретная CDN, да мало ли, а вдруг эти два имени и есть на самом деле виртхосты Апача, ведь это же один сервер по сути-то.
При этом такой человек совершенно не получает ответа на очень важный вопрос — а ЧТО там может быть указано в Host:? Каковы границы? Может ли при запросе на Амазон или на google.com там стоять Host: server.of.telega.com или вообще что угодно? Прикол-то ведь в том, что да, МОЖЕТ, но при условии, что… но ведь в статье этого момента нет!
Тащем-то, если кто-то дочитал до этого места, а из статьи это всё еще непонятно, то вот краткий ответ: с точки зрения протокола HTTP прокси-сервера и оригинальные не отличаются почти никак, и фронтенд сети CDN, например google.com, работает в качестве прокси-сервера — Вы действительно можете указать абсолютно любой Host: server.of.telega.com, при условии, что server.of.telega.com резольвится в IP-адрес, принадлежащий этой CDN (скорее всего, пресловутая Телега не разместит внутри такой CDN, гугловской или амазоновской, свои реальные сервера, а разместит ретрансляторы/прокси на них, но это уже вопрос другой). На этом месте может возникнуть вопрос, а в чем смысл такой огород городить? А вот как раз тут смысл всей затеи с фронтингом и появляется в шифровании — да, по HTTP было бы видно целевой заголовок Host: (и цензор смог бы вклиниться), но по HTTPS его НЕ видно! Поскольку все запросы будут идти к например google.com, т.е. сертификаты (и тот самый SNI) будут выписаны на google.com. Тут может возникнуть последний вопрос, а почему это не уязвимость, то есть, почему CDN именно так работают в штатном режиме? Да просто затем, чтобы иметь всегда один сертификат на фронтенд (грубо говоря, те условные 600 IP-адресов google.com или amazon.com), а не заводить его на каждую клиентскую виртуалку / доменное имя, которые, к тому же, могут меняться (число подсетей, etc.).
Вот такое объяснение у человека, который не задумывался и не в курсе многих деталей, действительно должно снять все вопросы.
Читаю ваш комментарий и понимаю что вы действительно не понимаете что делает CDN, каким образом работает, какое отношение имеет к "виртуалка" и Апачу, и так далее. Взять хотя бы объяснение про причины именно такой работы. Вы действительно считаете что под каждое доменное имя не заводят отдельную конфигурацию, или, например, не выделяют какие-то конкретные IP согласно внутренних алгоритмов CDN?..
Чтобы вам помочь и объяснить действительно все детали и особенности работы современных CDN, статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти. И это будет статья не про доменное прикрытие, а про архитектуру CDN.
Если у вас есть конкретные предложения по улучшению конкретно этой статьи, но не такие, чтобы статью пришлось увеличить в два раза, очень жду.
Человеку, который работал в Кураторе, "не понимаете что делает CDN"… смешно. На самом деле, корень противоречия здесь:
статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти
Между "как правильно" и "ленью" выбрали лень. И нет, чтобы объяснить этот вопрос, как я показал в своем предыдущем комменте (его и можно считать "как улучшить"), вовсе не требуется рассказывать "детали и особенности" архитектуры CDN. Например, для озвученного в заголовке вопроса неважен BGP ANYCAST. Зато важно, кому объясняется, например, можно предположить, что человек уже прочитал статью в википедии про CDN. И т.д.
Я вот только не понял, почему CDN работает как proxy…
Domain fronting: что это такое?