04.05.2018 04:00
alexkbs 35 17900 Источник


Вы уже наверняка слышали про domain fronting, особенно в контексте блокировки РКН серверов Google, отвечающих за сам google.com, и дальше последовавший запрет Google и AWS на использование их доменов для обхода блокировок.


Что же такое прикрытие доменом?


Domain fronting, или, в вольном переводе, прикрытие доменом — это способ обойти фильтры и блокировки, скрыв конечную цель соединения, использующий особенности CDN. Этот способ возможен потому что современные CDN содержат в себе две принципиальные части, которые существуют независимо друг от друга и, как правило, взаимодействуют друг с другом лишь в части установки TCP соединения друг с другом:


  1. Есть внешняя часть, отвечающая за установку защищенного соединения с передачей данных SSL сертификата.
  2. Есть внутренняя часть, отвечающая за обработку непосредственно отправленного запроса после расшифровки. Обычно — HTTP запроса.

Так как эти две части не имеют связи между собой, можно при обращении к первой части обратиться к одному сайту, а после установки защищенного соединения отправить запрос к другому сайту. Если это касается частных CDN, то обычно тут нет никакой проблемы, за редким исключением в виде доступа к внутренним ресурсам, к которым обычно доступа нет. Если это касается публичных CDN, в которых можно купить членство, вроде AWS CloudFront или аналогов от других компаний, то здесь всё сразу становится много интересней.


Как цензор видит CDN


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


В случае использования шифрования задача усложняется. Блокировка конкретного адреса страницы становится невозможной. Простейшим решением задачи блокировки сайта за HTTPS будет блокировка по IP. Даже если не используется CDN эта задача содержит ряд очень неприятных побочных эффектов. Если же используется CDN, то блокировка по IP становится зачастую невозможной: не сколько потому что на одном IP в CDN может быть много сайтов (РКН это не очень останавливало до сих пор), сколько потому что у сайта на CDN может быть много разных IP, которые невозможно знать заранее.


На выручку цензорам приходят совеременные браузеры, которые до установки защищенного соединения всегда посылают открытым текстом имя сайта, на который вы хотите зайти. Провайдерские и операторские DPI могут без проблем увидеть с каким именно сайтом устанавливается соединение, затем оборвать соединение или иным образом помешать.


Эксперимент


Давайте посмотрим, как установку соединения видит цензор, и как мы можем обвести цензора вокруг пальца. Для демонстрации мы используем tshark, хотя ту же демонстрацию можно провести с помощью tcpdump или через GUI в Wireshark.


В экспериментах используем этот же сайт, на котором вы читаете эту статью, так как он находится за CDN от QRATOR, которая обладает всеми необходимыми особенностями для демонстрации этого способа обхода цензуры. Сама эта демонстрация не говорит о том, что у используемой CDN от QRATOR есть какая-то уязвимость или проблема в безопасности: так до сих пор работали все CDN, и всё ещё работает большинство CDN. Точно такая же особенность есть, например, у CDN у Яндекса.


В одной консоли запустим:


tshark -T fields -Y 'tcp.dstport == 443 and ssl.handshake.extensions_server_name' -e ssl.handshake.extensions_server_name

Если tshark не хочет работать без sudo...

Под Debian эта проблема исправляется тремя командами:


sudo dpkg-reconfigure wireshark-common
sudo gpasswd -a $USER wireshark
newgrp wireshark

Под другими дистрибутивами YMMV. При прочих равных используйте sudo.


В соседней консоли обратимся к какому-нибудь сайту по HTTPS:


curl -sI https://habr.com

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


Capturing on 'eno1'
habr.com

Сюрприз для цензора


Не закрывая логгирование SNI, попробуем сэмулировать тот запрос, который посылает cURL:


(echo HEAD / HTTP/1.1
echo Host: habr.com
echo Connection: close
echo) | openssl s_client -quiet -servername habr.com -connect habr.com:443

Мы увидим тот же самый ответ, что и ранее, при вызове curl -sI https://habr.com. В выводе tshark всё так же: логгируется соединение с habr.com.


А теперь, не меняя заголовки запроса, обратимся не к habr.com, а по старому имени сайта:


(echo HEAD / HTTP/1.1
echo Host: habr.com
echo Connection: close
echo) | openssl s_client -quiet -servername habrahabr.ru -connect habrahabr.ru:443

Сюрприз, сюрприз! Ответ мы получили ровно тот же самый, что и раньше, но в логе tshark и в выводе openssl s_client значится что мы обращались к habrahabr.ru, а не к habr.com:


depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = habrahabr.ru

Такой же трюк можно сделать в обратную сторону:


(echo HEAD / HTTP/1.1
echo Host: habrahabr.ru
echo Connection: close
echo) | openssl s_client -quiet -servername habr.com -connect habr.com:443

В логах будет указано что мы обращались к habr.com, однако ответ будет соответствовать выводу:


curl -I https://habrahabr.ru

Не Хабром единым


Чтобы далеко не ходить, точно такой же трюк работает для сайтов Яндекса, использующих их собственную CDN:


(echo GET / HTTP/1.1
echo Host: music.yandex.kz
echo Connection: close
echo) | openssl s_client -quiet -servername music.yandex.ru -connect music.yandex.ru:443  | grep -Eo '<meta[^>]*?og:url[^>]*?>'

Лог цензора покажет что мы обращались к music.yandex.ru, а команда покажет что нам открылась главная страница music.yandex.kz:


<meta property="og:url" content="https://music.yandex.kz/home"/>

Что здесь вообще происходит?


На блок-схеме наши запросы выглядят примерно так:



С точки зрения соединения мы подключаемся к одному сайту, например, google.com, но с точки зрения протокола HTTP запрос делаем к совершенно другому сайту, который лишь по случаю находится в той же CDN.


(Иллюстрация выше — из большой обзорной статьи на английском, рассматривающей историю вопроса, возможные альтернативы и прочие подробности использования доменного прикрытия.)


Что тут можно сказать?


Мы на практике убедились что мы можем отправить запрос к одному сайту за HTTPS, а цензор увидит что мы обращались к совершенно другому сайту. Именно таким образом Signal больше года обходил блокировку в Египте и некоторых других странах, прикрываясь google.com, пока сначала Google и затем Amazon не запретили им использовать свои сайты и сайты своих клиентов для обхода цензуры.


Телеграм тоже использует этот метод обхода цензуры. Желающие могут без особого труда найти в исходниках официальных клиентов как именно это делается в Телеграме, и какие CDN используются.


Понятно что от доменного прикрытия на CDN Хабра и Яндекса нет ровным счётом никакой практической пользы если у вас нет своего сайта, который использует ту же самую CDN, потому, ещё раз повторюсь, эта особенность CDN пока не считается уязвимостью произвольной CDN как таковой. Не спешите бежать на HackerOne заводить отчёты: your report сlosed as not applicable — это всё, что вы, пока, получите.


Такая ситуация приводит к тому, что большинство современных CDN в той или иной мере могут быть использованы для прикрытия чужим доменом.


Задача поиска доменов с высокой репутацией, размещенных на CDN, заблокировать которые решится не всякий цензор, требует лишь времени и упорства. Например, на CDN находятся многие популярные домены вроде media.tumblr.com, images.instagram.com, cdn.zendesk.com и cdn.atlassian.com, которые могут использоваться для доменного прикрытия. Никакого недостатка в таких популярных, а значит подходящих, доменах нет.


Служат ли злу Google и Amazon?


Возникает законный вопрос: если Google и Amazon не хотят помогать обходить цензуру, то означает ли что они прислуживают всемирному злу? На этот ответ нельзя дать однозначный ответ, так как есть факты использования доменного прикрытия не только для обхода цензуры, но и для несанкционированного удалённого доступа при взломах.



Понятное дело Google и Amazon не хотят иметь никакого отношения к взломщикам и прочему криминальному элементу, использующему их порядочные домены для своих грязных дел.


Последнее наблюдение говорит о том, что, к сожалению, можно ожидать что все другие CDN постепенно последуют вслед за Google и Amazon, запретив или ограничив у себя описанные возможности для обхода цензуры и блокировок.


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

Комментарии (35)


  1. altrus
    04.05.2018 07:24
    #10788168
    -3

    Хорошая статья
    image


  1. SDKiller
    04.05.2018 09:08
    #10788306
    +1

    В новостях российских СМИ по этому поводу можно было видеть много примеров того, как "ученый изнасиловал журналиста".


    От "гугл/амазон запретили использовать свой сервис для обхода блокировок Роскомнадзора" до "амазон запретил использование прокси-серверов".


    Так что всегда лучше читать оригинал.


    1. Carburn
      04.05.2018 09:53
      #10788394

      Domain fronting это использование CDN в качестве HTTP-прокси.


      1. ivan386
        04.05.2018 10:09
        #10788412

        CDN по сути и есть обратный кеширующий прокси. Другое дело что конечный сервер к которому CDN подключается тоже может работать как прокси давая доступ уже ко всему интернету.


        А в случае когда прикрытие домена используется просто для доступа к обычному сайту в этой сети то разницы для CDN не должно быть.


  1. ivan386
    04.05.2018 09:57
    #10788402

    Стоит добавить что в браузере прикрытие доменом реализуется простым proxy.pac только если сайт форсированно не переводит на https.


    function FindProxyForURL(url, host)
{
 if (host == "[заблокированный домен]" && shExpMatch(url, "http:*"))
    return "HTTPS [не блокируемый домен];"; 
 else
    return "DIRECT";
}

    Алгоритм действий такой.


    1. Заходим на sslchecker
    2. Вводим заблокированный домен
    3. В поле SAN выбираем рабочий не заблокированный домен
    4. Проверяем выбранный домен(должен открываться по https)
    5. Подставляем домены в proxy.pac скрипт соответственно

    Данный скрипт сработает для адреса http://[заблокированный домен]


    1. ivan386
      04.05.2018 12:31
      #10788686

      Возможно данный метод будет работать и для сайтов у которых нет https вообще. Надо найти сайт на том-же IP у которого будет https и им прикрыть.


      1. alexkbs Автор
        04.05.2018 16:41
        #10789050

        Уже сама формулировка "сайт без https" в наше время вызывает вопросы. Let's Encrypt опять же.


        1. ivan386
          04.05.2018 20:00
          #10789300

          Ну почему то bittorrent.org не озаботились сертификатом для сайта. Но с этим сайтом этот метод не работает.


        1. firedragon
          04.05.2018 22:43
          #10789386

          Скачивать болванки подписанные ключами, через vpn и ssl, вам не кажется, что легче, презерватив на роутер надеть?

          Отдельные лучи света всяким фильмам, видосам и поклонникам BD рипов.
          В общем много много тон угля сгорает что бы защитить порнуху.


          1. alexkbs Автор
            07.05.2018 04:35
            #10791270

            Современные и даже уже устаревшие процессоры легко делают AES со скоростью больше гигабайта в секунду, о каких тоннах угля вы говорите? Десять-пятнадцать лет назад шифрование может быть и было проблемой, но в наше время затраты на шифрования ничтожны по сравнению с преимуществами в части безопасности и конфиденциальности, которые оно даёт.


  1. lostmsu
    04.05.2018 10:16
    #10788418

    Печально, что AWS и Гугл прогнулись под это. Если только это не приводит к каким-нибудь странным уязвимостям.


    1. firedragon
      04.05.2018 10:43
      #10788460

      AWS и Гугл зарабатывают деньги. И в еуле есть пункт что клиент не должен нарушать законодательство и создавать проблемы своими действиями соседям.
      Впрочем производители железа потирают руки, как и производители OC


      1. lostmsu
        04.05.2018 10:46
        #10788464

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


        1. altrus
          04.05.2018 11:05
          #10788498
          -1

          Деньги тут не первостепенны. Телеграм своими действиями нарушает бизнес партнеров Гугла и Амазон, которые у них хостятся. Это естественно, что те пытаются их защитить. На кону их репутация.


          1. alexkbs Автор
            04.05.2018 11:16
            #10788518

            Не Телеграм, а Signal. И даже не Signal, а хакеры из группы APT29. До того как эти личности начали для своих тёмных делишек использовать эту возможность, никому не было дела до того что Signal использует google.com для обхода цензуры. В статье даже написано что Signal пользовался этим приёмом больше года. Всё это время его приёмы никому не мешали.


            1. altrus
              04.05.2018 11:25
              #10788540

              Естественно не мешали — РКН ведь не блокировал сервисы Гугла и Амазона из-за Signal тогда, и всё работало. А как из-за телеграм->РКН->блокировок пошли проблемы у клиентов сетевых монстров (пусть даже только в России), тогда они и зашевелились.

              На сами по себе разборки РКН-Телеграм им плевать. я думаю. Бизнес защищает только свои инвестиции.


              1. dartraiden
                04.05.2018 14:37
                #10788854

                В эту теорию не вписывается то, что Google запретил domain fronting ещё до начала ковровых бомбардировок Телеграма в России.

                Об этом стало известно 13 апреля, следовательно, решение внутри корпорации было принято ещё раньше.

                К тому же, говорят, что domain fronting для Google AppEngine не использовался Телеграмом вообще.


                1. altrus
                  04.05.2018 14:48
                  #10788876

                  Ну тогда в эту теорию не вписывается и само предположение, что это решение Гугла как-то связано с Телеграм.
                  И вся дискуссия беспредметна.


  1. ibKpoxa
    04.05.2018 11:01
    #10788488

    А Сысоев это предвидел :) Еще 4 года назад в nginx реализовал возможность проверки соответствия домена в sni и домена в Host: через переменные $host и $ssl_server_name.


    1. alexkbs Автор
      04.05.2018 11:53
      #10788592

      По умолчанию и из коробки такая проверка не делается, правильно?


      1. ibKpoxa
        04.05.2018 12:07
        #10788610

        Верно, надо настраивать, есть есть необходимость.


  1. erondondon
    04.05.2018 21:00
    #10789326
    -3

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


  1. vsb
    04.05.2018 22:29
    #10789370
    -1

    SNI позволяет избежать бана серверов по IP, если у провайдера есть DPI. Но в TLS 1.3 имя домена более не будет передаваться незашифрованным. Любопытно посмотреть, будут ли переходить подобные сервисы на TLS 1.3 рискуя получить бан по IP или же останутся на 1.2?


    1. Chupaka
      07.05.2018 00:03
      #10791160

      К сожалению, в tls1.3 имя в sni осталось нешифрованным. Я тоже сначала понадеялся, что пришло тотальное шифрование, но нет — Wireshark видит имя сайта, на котором Chrome показывает TLS 1.3 :(


      1. firk
        07.05.2018 10:25
        #10791622
        +1

        Шифровать SNI — весьма глупое занятие, по как минимум двум причинам. Во-первых, зашифровать его с хоть малейшей претензией на криптостойкость возможно только в ситуации, когда смысл этого этого расширения полностью потеряется (пока сервер вам не прислал сертификат, вам могут сделать mitm и всё расшифровать, а пока вы серверу не пришлёте hostname, он не сможет прислать вам сертификат, либо сервер должен слать сразу сертификаты ко всем хостяшимся у него доменам, но тогда SNI ему уже не нужен). Во-вторых, мне сложно представить хоть какое-то этому применение, кроме попыток обхода блокировок с последующими ip-банами, а TLS делается для бытовой приватности и бизнес-нужд, а вовсе не для подпольной борьбы с чиновниками.


        1. Chupaka
          07.05.2018 11:25
          #10791774

          Ну, в tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 во вступлении описывают, зачем это всё делается. А на фоне Domain Fronting банов по IP уже практически не избежать.


        1. ivan386
          07.05.2018 11:28
          #10791790
          +1

          Тем не менее стандарт разрабатывается: SNI Encryption in TLS Through Tunneling.
          И есть два решения:


          1. Tunneling TLS in TLS
            Который работает аналогично прикрытию домена только на втором этапе создаётся уже шифрованный канал к целевому серверу. Для первой части могут быть использованы сертификаты выданные на IP а не домен. Новые соеденения с сервером уже могут быть установленны используя 0-RTT который вроде как открытого SNI уже не требует.
          2. SNI encryption with combined tickets
            Этот вариант я пока не разобрал.


          1. firk
            07.05.2018 13:37
            #10792114

            Я курсе что разрабатывается, но эти решения — не решения указанной мной проблемы. Защита от mitm начинается только после того, как вы проверили сертификат домена. Следовательно, и ваш запрос на его получение, и само содержание сертификата принципиально невозможно защитить от просмотра. Про mitm вы узнаете только после проверки — можете рвать соединение, но запрашиваемое имя сервера уже перехвачено.


  1. firk
    05.05.2018 04:21
    #10789564
    +1

    Возникает законный вопрос: если Google и Amazon не хотят помогать обходить цензуру, то означает ли что они прислуживают всемирному злу? На этот ответ нельзя дать однозначный ответ, так как есть факты использования доменного прикрытия не только для обхода цензуры, но и для несанкционированного удалённого доступа при взломах.

    Тут употреблено правильное выражение: "не хотят помогать". Речь тут идёт действительно именно в категориях "помогать/не помогать", а не "не мешать/мешать" (видите разницу?), как некоторые это воспринимают и обижаются. Пулы айпи-адресов стоят довольно много денег, эти деньги на них потратил условный амазон, а вы теперь хотите, чтобы вам за просто так дали ими пользоваться. Клиенты, которые на этих пулах сидят (и, местами, прикрывают их от блокировок), стоят ещё больше денег, и амазон, опять же, вложил много своих средств ради привлечения этих клиентов. А кто-то вдруг хочет всем этим (большим пулом адресов, из которых можно выбирать, и соседством с важными клиентами. которых не будут блокировать) воспользоваться по сути забесплатно (по цене одной виртуалки или что там надо заказать чтобы тебе дали адрес). Нет, выгоду от своих вложений амазон вполне логично забирает себе, а клиенту с одной виртуалкой дают только то, что он заказал. И от соседей максимально огораживают, чтобы он не эксплуатировал соседство с ними, которое в цену услуги, естественно, не входит.


  1. Chupaka
    07.05.2018 00:11
    #10791166
    +1

    Приложения такое, в целом, и без публичных CDN могут использовать: делать запрос на свой сервер, указывать в SNI хост google.com, а внутри шифрованного канала (да хоть бы и с самоподписанным сертификатом для google.com — вряд ли законотворцы обяжут все сайты подписываться только одобренными доверенными CA) передавать всё, что угодно — это ведь Гуглом не запрещается, ибо их CDN не задействован? Или я что-то упустил?


    1. alexkbs Автор
      07.05.2018 04:18
      #10791258

      Нет, не упустили. Эта идея действительно сработает если цензор не будет присматриваться к деталям, а это будет если ваше приложение (а мы говорим об обходе цензуры для приложений), не будет представлять сколько-нибудь особого интереса. Телеграм явно не такое приложение никому не интересное приложение. Потому такую идею будет сложно применить на практике для сколько-нибудь популярных приложений.


      1. Chupaka
        07.05.2018 07:17
        #10791324

        Ну, а в текущих реалиях, когда Телеграм меняет IP-адреса, как перчатки — РКН сможет ли с таким что-либо сделать, кроме продолжения выкашивания огромных подсетей? =)


        1. alexkbs Автор
          07.05.2018 07:32
          #10791346
          +1

          Телеграм не просто может менять IP адреса, а может и выдавать разным людям — разные IP адреса. Значит цензура просто не сможет знать все IP адреса, которыми пользуется Телеграм, подглядывая за работой официального клиента. Даже блокировкой подсетей от этого не защититься: ведь как заблокировать то, не знаешь что?..


          Значит тут остаётся только вариант прессовать провайдеров облачных услуг чтобы те выгнали Телеграм со своих мощностей, что и происходит. РКН сейчас как такие гопники-рэкетиры пытаются сыграть с Телеграмом ещё раз ту карту, с которой у них получилось раньше с Zello, без стеснения заявляя что символично блокируют ровно половину IP адресов AWS. Правда, учитывая незначительность российского рынка для облачных компаний, важность облачных сервисов для российских организаций, и политический накал ситуации (Жаров находится под санкциями), в этот раз трюк пока не работает так, как в прошлый раз.


  1. nuclight
    07.05.2018 04:19
    #10791262

    Статье низачот. Поскольку приведено, как это происходит (но лишь вскользь про две части), но не объяснено, почему это происходит. От дампов с другим Host: немного толку — это и так было ясно. То есть, пришедший со стороны пользователь, желающий разобраться с тем, что Telegram это использовал, или с вопросом, «а что же такое в сети Google раньше работало, как они сказали, побочным эффектом, а теперь отменено?» — останется без ответа. Тут без упоминания proxy и RFC 2616 вряд ли обойтись.


    1. alexkbs Автор
      07.05.2018 04:25
      #10791264

      Простите ради бога, но если бы подобная статья была совсем для совсем далёких от IT читателей, которые ни одной идеи о работе HTTP не имеют, то какое место такой статье было бы на Хабре, который позиционирует себя как крупнейший в Европе ресурс для IT-специалистов? У нас тут технически подкованная аудитория, которую не удивишь RFC 2616. На Хабре да на пальцах рассказывать про заголовок Host — всё равно что своих читателей не уважать.