Domain fronting: что это такое?


    Вы уже наверняка слышали про 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, подумайте, может ли кто-нибудь использовать ваши услуги для подобных, несоответствующих ожидаемым, целям, и как вы к этому относитесь. Если не запрещать, то стоит хотя бы знать, что что-то такое может делаться на вашей территории.

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 45
      –30
      Хорошая статья
      image
        +4

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


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


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

          –2

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

            +1

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


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

          +1

          Стоит добавить что в браузере прикрытие доменом реализуется простым 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://[заблокированный домен]

            0

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

              0

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

                0

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

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

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

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

                      0

                      Шифрованный трафик не кешируется оператором.

              +1
              Печально, что AWS и Гугл прогнулись под это. Если только это не приводит к каким-нибудь странным уязвимостям.
                –2
                AWS и Гугл зарабатывают деньги. И в еуле есть пункт что клиент не должен нарушать законодательство и создавать проблемы своими действиями соседям.
                Впрочем производители железа потирают руки, как и производители OC
                  +3
                  Есть какие-то границы того, до какой степени деньги могут быть единственным мотиватором. Тема с domain fronting, имхо, как раз на границе добра из зла.
                    –7
                    Деньги тут не первостепенны. Телеграм своими действиями нарушает бизнес партнеров Гугла и Амазон, которые у них хостятся. Это естественно, что те пытаются их защитить. На кону их репутация.
                      +9

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

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

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

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

                          К тому же, говорят, что domain fronting для Google AppEngine не использовался Телеграмом вообще.
                            0
                            Ну тогда в эту теорию не вписывается и само предположение, что это решение Гугла как-то связано с Телеграм.
                            И вся дискуссия беспредметна.
                +5
                А Сысоев это предвидел :) Еще 4 года назад в nginx реализовал возможность проверки соответствия домена в sni и домена в Host: через переменные $host и $ssl_server_name.
                  0

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

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

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

                        +1
                        Шифровать SNI — весьма глупое занятие, по как минимум двум причинам. Во-первых, зашифровать его с хоть малейшей претензией на криптостойкость возможно только в ситуации, когда смысл этого этого расширения полностью потеряется (пока сервер вам не прислал сертификат, вам могут сделать mitm и всё расшифровать, а пока вы серверу не пришлёте hostname, он не сможет прислать вам сертификат, либо сервер должен слать сразу сертификаты ко всем хостяшимся у него доменам, но тогда SNI ему уже не нужен). Во-вторых, мне сложно представить хоть какое-то этому применение, кроме попыток обхода блокировок с последующими ip-банами, а TLS делается для бытовой приватности и бизнес-нужд, а вовсе не для подпольной борьбы с чиновниками.
                          0
                          Ну, в tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 во вступлении описывают, зачем это всё делается. А на фоне Domain Fronting банов по IP уже практически не избежать.
                            +1

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


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

                                На IP также выдаются сертификаты и их тоже можно проверить. После этого внутри тунеля установленного по IP можно установить соединение по домену.

                                  0
                                  На IP также выдаются сертификаты и их тоже можно проверить.

                                  А ещё некоторые считают, что если скаченный с рандомного сайта софт имеет валидный сертификат (с именем "Vasya Pupkin Ltd") — то он точно без вирусов.


                                  После этого внутри тунеля установленного по IP можно установить соединение по домену.

                                  А давайте ещё весь TOR-протокол в TLS засунем — чтобы никто не знал, кто с кем соединяется. У TLS другое назначение — давать каналу связи криптографическую защиту от прослушивания/подделки. Скрывать тот факт, что две известные стороны соединились друг с другом, там не планировалось — это никак не помогает его целям, но становится вообще бесполезным, когда вас и вашего партнёра просто вычислят по ай-пи (далеко не у всех сайтов ай-пи принадлежит безымянному общему cdn, ну а про клиентов и говорить нечего). Всякие прокси-подобные механизмы мутного назначения, очевидно, существуют, но в спецификации протокола поточного шифрования им не место.

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

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

                          +1

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

                            0

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

                              0

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

                                +1

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


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

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

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

                                0
                                Видите ли, я, как человек, написавший энное количество «просветительских» статей, вполне имею право позанудствовать и потребовать объяснений в «правильном стиле», даже если сам могу по обрывкам нателепатировать, что ж там на самом деле (ибо в объяснениях нуждается как раз тот, кто не может). Да и ударяться в бинарные крайности — плохо и неправильно. Во-первых, почему Вы решили, что статья ограничена аудиторией Хабра? Было бы гораздо более логично предполагать, что сюда попадут многие из поисковика по запросу «что такое domain fronting», и здесь следует предполагать уровень «в курсе о HTTP для самых стандартных случаев, не дальше». Во-вторых, а с чего Вы взяли, что большинство аудитории Хабра читало тот же RFC 2616 от корки до корки?.. Собственно, тут у Вас внутреннее противоречие, ведь если бы это было так, то и статья была бы не нужна, ведь все бы просто сразу, держа в уме весь документ, понимали логическое следствие.

                                То есть, надо иметь в виду приблизительный портрет читателя. Например, человек прочитал журналистскую новость «вот, раньше для объода блокировки через Гугль работало, а теперь не работают, они объясняют это косяком с настройками и случайностью, а не фичей». Человек из такого объяснения ессно нифига не понимает, и (если он немножко технарь и интересуется) начинает искать, а что же это такое. Положим, он хотя бы раз набирал в 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.).

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

                                  Читаю ваш комментарий и понимаю что вы действительно не понимаете что делает CDN, каким образом работает, какое отношение имеет к "виртуалка" и Апачу, и так далее. Взять хотя бы объяснение про причины именно такой работы. Вы действительно считаете что под каждое доменное имя не заводят отдельную конфигурацию, или, например, не выделяют какие-то конкретные IP согласно внутренних алгоритмов CDN?..


                                  Чтобы вам помочь и объяснить действительно все детали и особенности работы современных CDN, статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти. И это будет статья не про доменное прикрытие, а про архитектуру CDN.


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

                                    0

                                    Человеку, который работал в Кураторе, "не понимаете что делает CDN"… смешно. На самом деле, корень противоречия здесь:


                                    статью нужно сделать в два раза длинней. Извините, на такое я не готов пойти

                                    Между "как правильно" и "ленью" выбрали лень. И нет, чтобы объяснить этот вопрос, как я показал в своем предыдущем комменте (его и можно считать "как улучшить"), вовсе не требуется рассказывать "детали и особенности" архитектуры CDN. Например, для озвученного в заголовке вопроса неважен BGP ANYCAST. Зато важно, кому объясняется, например, можно предположить, что человек уже прочитал статью в википедии про CDN. И т.д.

                                      0
                                      Как и комментаторы, которым что-то не лень писать комменты, а вот написать свою правильную статью с блек.. с полным разбором всего нужного. Помиритесь :)
                              0
                              Понять Google и Amazon как бизнес можно, но стоит подумать о том, что закрывая намертво двери от воров и грабителей, можно оставить и добропорядочных гостей (клиентов, соседей,...) на улице. Я вот думаю — а в каких случаях описанный способ будет работать на благо клиента и при этом не нарушать правила сервиса и законы? Если добропорядочным клиентам такой способ нужен не меньше, чем криминальным элементам, то Google и Amazon фактически пилит сук, на котором сидит.
                                0
                                Приведите пример, когда подобное требуется добропорядочному клиенту, я не смог такого представить, но могу и ошибаться.
                                  0

                                  Тут как минимум нужно определить, что такое "добропорядочный". А с этим проблемы :(

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое