DNS по HTTPS – половинчатое и неверное решение

Original author: Maya Posch
  • Translation


Всё время существования интернета открытость была одной из его определяющих характеристик, и большая часть сегодняшнего трафика всё ещё передаётся без какого бы то ни было шифрования. Большая часть запросов HTML-страниц и связанного с этим контента делается в простом текстовом виде [plain text], и ответы возвращаются тем же способом, несмотря на то, что протокол HTTPS существует с 1994 года.

Однако иногда возникает необходимость в безопасности и/или конфиденциальности. Хотя шифрование интернет-трафика получило широкое распространение в таких областях, как онлайн-банки и покупки, вопрос сохранения конфиденциальности во многих интернет-протоколах решался не так быстро. В частности, при запросе IP-адреса сайта по хосту DNS-запрос почти всегда передаётся открытым текстом, что позволяет всем компьютерам и провайдерам по пути запроса определить, на какой сайт вы заходите, даже если вы используете HTTPS после установления связи.

Идея о необходимости шифрования также и DNS-запросов не нова, и первые попытки этого делались ещё в 2000-х — DNSCrypt, DNS over TLS (DoT), и т.п. Mozilla, Google и другие крупные интернет-компании продвигают новый метод шифрования DNS-запросов: DNS over HTTPS (DoH).

DoH не только шифрует DNS-запрос, но и передаёт его «обычному» веб-серверу, а не DNS-серверу, благодаря чему DNS-трафик невозможно отличить от обычного HTTPS. У этой монеты есть две стороны. Эта процедура защищает сам DNS-запрос, как DNSCrypt или DoT, а также делает невозможным ребятам из служб безопасности крупных фирм отслеживать DNS-спуфинг, и переносит ответственность за критически важные функции сети с ОС в приложение. И также это никак не помогает скрыть IP-адрес веб-сайта, который вы только что запросили – ведь вы всё равно на него переходите.

По сравнению с DoT, DoH централизует информацию о посещённых вами сайтах в нескольких компаниях: на сегодня это Cloudflare, обещающая избавляться от ваших данных через 24 часа, и Google, которая намерена сохранить и монетизировать все подробности всего, что вы когда-либо планировали сделать.

DNS и конфиденциальность – важные темы, поэтому давайте углубимся в детали.

DNS-сервера и доверие


Концепция системы доменных имён восходит ещё к ARPANET, когда в единственном текстовом файле на каждом узле ARPANET – под названием HOSTS.TXT – содержалось всё соответствие названий систем, подключённых к ARPANET и их цифровых адресов. Когда вы самостоятельно пополняли этот файл, легко было убедиться в его правильности. С ростом сети стало нереально поддерживать центральную и локальные копии этих файлов. К началу 1980-х уже начались попытки создания системы автоматизации этого процесса.

Первый сервер имён (Berkeley Internet Name Domain Server или BIND) был написан в 1984 году группой студентов Калифорнийского университета в Беркли на основе RFC 882 и RFC 883. К 1987 году стандарт DNS был несколько раз пересмотрен, что привело к появлению RFC 1034 и RFC 1035, которые с тех пор по большому счёту не менялись.



Основа структуры DNS состоит в её древовидной схеме, где узлы и листья делятся на зоны. Корневая зона DNS – это верхний уровень, состоящий из тринадцати кластеров корневых серверов, формирующих официальные корневые DNS-сервера. Любой новый DNS-сервер (поднятый провайдером или компанией) получает DNS-записи по меньшей мере от одного из этих главных серверов.

Каждая последующая DNS-зона добавляет ещё один домен к системе имён. Обычно каждая страна обслуживает собственные домены, а домены типа .org или .com, не привязанные к странам, обслуживаются отдельно. Запрос имени хоста через DNS начинается с имени домена (к примеру, .com), затем с названия (например, google), за которым следуют возможные поддомены. Если данные ещё не попадали в кэш, для разрешения запроса может потребоваться совершить несколько переходов по DNS-зонам.

DNSSEC: добавляем доверие в систему DNS


Перед тем, как перейти к шифровке DNS-запросов, нужно убедиться, что мы можем доверять DNS-серверу. Эта необходимость стала очевидной в 1990-х, и привела к появлению первых рабочих расширений стандарта безопасности DNS (DNSSEC), RFC 2353 и пересмотренного RFC 4033 (DNSSEC-bis).


Карта интернета 2006 года

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

Хотя DNSSEC позволяют быть относительно уверенным в том, что ответы от DNS-сервера настоящие, этот протокол нужно включить в ОС. К сожалению, мало какие ОС реализуют сервис DNS, способный на нечто большее, чем просто «знать о наличии DNSSEC» – то есть, они на самом деле не подтверждают ответы DNS. А значит, сегодня нельзя быть уверенным в том, что получаемые вами ответы от DNS настоящие.

Проблема с DoH


Представим, что вы используете DNSSEC. Вы готовы зашифровать сообщения, чтобы добавить вашей передаче данных конфиденциальности. Причин для того, чтобы сохранить DNS-запросы в секрете от любопытных глаз, может быть много. Среди самых невинных — обход фильтров корпорации и провайдеров, запрет отслеживания интернет-привычек, и прочее. Среди более серьёзных — попытки избежать преследования со стороны правительства за выражение политических взглядов в интернете. Естественно, что шифрование DNS-запросов не даёт людям подсматривать эти запросы, однако в результате игнорируются более крупные проблемы с безопасностью DNS, и, естественно, всех остальных протоколов связи.

Основными конкурентами здесь являются DoT с использованием TLS и DoH с использованием HTTPS. Самая очевидная разница между ними – это порт: DoT работает на выделенном порту TCP 853, а DoH смешивается с другим HTTPS-трафиком на порту 443. Это даёт спорное преимущество неотличимости DNS-запросов от остального трафика, что лишает возможности операторам сети (частным и корпоративным) обезопасить собственную сеть, как в прошлом году заявил в своём твиттере один из архитекторов DNS Пол Викси.

Второе из главных отличий состоит в том, что если DoT просто отправляет DNS-запросы по TLS, то DoH по сути представляет собой DNS-over-HTTP-over-TLS, требует своего Media Type application/dns-message, и значительно всё усложняет. Смешение DoH с существующими протоколами приводит к тому, что каждый DNS-запрос и ответ проходят через стек HTTPS. Это кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования.

У DoT есть ещё одно преимущество – этот протокол уже реализован, и гораздо дольше, чем существует DoH, используется такими компаниями, как Cloudflare, Google, а также местными интернет-провайдерами; такое стандартное серверное ПО, как BIND, использует DoT прямо «из коробки». На ОС Android Pie (9-я версия) DNS через TLS будет использоваться по умолчанию, если выбранный сервер DNS поддерживает DoT.

Зачем переключаться на DoH, если DoT уже раскручивается? Если такие нестандартные приложения, как Firefox, будут обходить системную DNS на базе DoT, и использовать собственную систему получения доменных имён через DoH, то с точки зрения безопасности эта ситуация станет весьма сложной. Передача DNS на откуп отдельным приложениям, происходящая сейчас, кажется шагом назад. Известно ли вам, какой метод DNS использует каждое из приложений? Узнаете ли вы о том, что оно смешивает этот процесс с TCP-трафиком на 443-м порту?

Шифрование не препятствует слежке


За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.

Кроме DoH, они упоминают стандарт QNAME minimization (RFC 7816), который должен уменьшить количество некритичной информации, отправляемой DNS-сервером. При этом этот стандарт никак не зависит от DoH и будет работать без всякого шифрования DNS. Как в случае с DNSSEC, безопасность и конфиденциальность улучшаются через эволюцию стандарта DNS.

Самое же интересное содержится в разделе «Чего не исправляет TRR + DoH»? Как уже говорили многие эксперты, шифрование DNS не препятствует отслеживанию. Любой последующий запрос к IP-адресу, который был получен ужасно секретным способом, всё равно будет ясно виден. Все всё равно будут знать, что вы зашли на Facebook.com, или на сайт для диссидентов. Никакое шифрование DNS или интернет-трафика не скроет информацию, жизненно необходимую для работы такой сети, как интернет.

Станет ли будущий интернет единой точкой отказа?


Mozilla предлагает справляться с проблемой отслеживания IP просто заявляя, что это не проблема благодаря использованию Облака. Чем больше веб-сайтов и сетей распространения контента (CDN) навесят на небольшое количество сервисов (Cloudflare, Azure, AWS, и т.п.), тем меньше будет значить этот единственный IP-адрес – нужно будет просто верить в то, что выбранный вами облачный сервис не будет воровать ваши данные и не упадёт на сутки.

В этом году 24 июня было массивное падение сервисов, когда ошибка в настройках, сделанная провайдером Verizon, привела к тому, что Cloudflare, Amazon, Linode и многие другие большую часть дня были недоступны. 2 июля этого года примерно на полчаса упал Cloudflare, а вместе с ним и многие веб-сайты, полагающиеся на его услуги.

По совпадению, облачный сервис Office365 от Microsoft тоже лежал в тот день несколько часов, из-за чего многие пользователи не смогли воспользоваться его услугами. В выходные перед днём труда [национальный праздник в США, отмечаемый в первый понедельник сентября / прим. перев.] отключение напряжения в дата-центре AWS US-East-1 привело к тому, что терабайт хранившихся там данных клиентов накрылся медным тазом. Очевидно, в идее о благе централизации интернета есть ещё какие-то недостатки.

Старые песни по-новому


Потрясающе, что во всей этой дискуссии по поводу конфиденциальности и отслеживания нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами, с сокрытием IP-адреса и прочим, просто перемещая точку, в которой ваш ПК или другое выходящее в интернет устройство соединяется с интернетом. Диссиденты внутри авторитарных режимов десятилетиями использовали VPN для обхода интернет-цензуры; VPN, включая такие его специальные виды, как Tor, являются критически важным элементом свободы в интернете.


Как работает Tor

Если вы доверяете большой коммерческой компании вроде Cloudflare в такой схеме, как DoH, то найти доверенного VPN-провайдера, не хранящего и не продающего ваши данные, будет легко. А в браузере Opera вообще есть бесплатная встроенная поддержка proxy, предлагающая множество преимуществ VPN.

В итоге можно сказать, что DoH подтверждает свой акроним, плохо делая то, что уже хорошо удаётся DoT [«Doh!» – восклицание, указывающее на глупость совершённого действия, особенно собственного / прим. перев.]. Нужно больше концентрироваться на повсеместном внедрении DNSSEC, совместно с DoT и минимизацией QNAME. А если вас заботит реальная конфиденциальность, то вам нужно обратиться к VPN.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 23

    +12
    О, Comcast начал деньги заносить журналистам :)
      0

      Get the facts v2.0

      0
      А, разве, bind поддерживает DoT без дополнительных костылей? Я, наивный, unbound в качестве прослойки для bind`а прикручивал.
        +2
        тупой вопрос: а нельзя использовать оба протокола? dot для начального открытия сайта и doh для продолжения работы на нем. тогда оба товарища не будут иметь полные данные об днс запросах юзера
          0
          Тут два момента:
          1. Если IP адрес целевого сервера уже определён то зачем резолвить ещё что-то? Просто его используем. И да, обращения к нему тот же провайдер легко зафиксирует/заблокирует по IP.
          2. По второму протоколу можно резолвить IP адреса серверов с которых грузится весь подгружаемый контент, будь то что шрифты/стили/JS скрипты/картинки/видео. Как раз на CDN его сейчас и разворачивают.

          В итоге шума будет больше, а толку-то почти нет: да, условный провайдер не подменит DNS, уже плюс. Но как отслеживал соединения так будет отслеживать.
          +8
          В форме сообщения об ошибке в тексте не работает кнопка «отправить», поэтому я напишу здесь. Вместо
          на самом деле не подтверждают ответы DNS
          должно быть
          на самом деле не проверяют ответы DNS

          Я понимаю, что это перевод, однако статья является типичным FUD (то есть примером акта манипуляции и пропаганды). Компиляция случайных фактов, которые не связаны с основной темой, отсутствие технических аргументов против технологии, (ложное) апеллирование к авторитетным мнениям могут указывать на заказной характер этой статьи.

          Углублюсь в детали.

          DNSSEC

          Это технология, которая:
          1. Не нашла широкого распространения. Очень малая доля доменов имеют подпись.
          2. Предназначена для проверки подлинности, а не обеспечения конфиденциальности запросов. К задачам, решаемым DoH, не имеет никакого отношения.

          Из этого упоминания автор статьи попытался наскрести повод, чтобы бросить тень сомнения на реализации DoH, предлагаемые Google и Cloudflare:
          За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.

          Тем не менее, рекурсивные резолверы Google и CF валидируют DNSSEC. Вместе с этим, ответы DNSSEC может валидировать и DNS-форвардер на офисном или домашнем шлюзе. Стоит заметить, что технология DNSSEC имеет свои проблемы внедрения и одно из требований для полноценного обеспечения гарантий, которые может предоставить эта технология, — это обеспечение безопасного канала между DNS-клиентом и рекурсором, проверяющим подлинность DNSSEC. DoH и DoT в этом случае абсолютно уместны и делают внедрение DNSSEC практичным.

          Проблема с DoH

          В этой части я ожидал увидеть технические проблемы протокола, однако увидел только три полуправдивых утверждения, не доказывающих основной тезис. По порядку:
          1. Аргумент о том, что операторы сети теряют контроль над сетью и апеллирование к мнению Пола Викси. Если проследовать по ссылке, то можно заметить, что его в первую очередь не устраивает формат транспорта внутри HTTPS и вместо этого он рекомендует использовать DoT. Что же касается контроля над трафиком пользователя, то это соответствует изначальной цели протокола. Более того: в корпоративной среде, использующей MITM-фильтрацию и собственные CA-сертификаты для неё, задача фильтрации остаётся решаемой.
          2. Этот тезис раскрывается дальше про передачу запросов через HTTPS заявлено, что это «кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования». Это заявление не выдерживает критики, так как везде DNS обычно реализован программно, а встраиваемое оборудование может получать преимущество от DoH/DoT, настренного для всей сети. Кроме этого, в следущем абзаце зачем-то упомянут VPN и TOR, которые уж точно не представлены в массе (особенно TOR) ни на каких встраиваемых устройствах.
          3. Далее идёт утверждение о том, что DoT более зрелый и имеет большее распространение. Однако, DoH труднее заблокировать и он может получать преимущества в сетевом обмене, используя HTTP/2 Server Push.

          Шифрование не препятствует слежке

          Такое можно сказать о любом шифрованном оверлее через сеть: выходная точка видит нешифрованный трафик. Однако, это существенно сокращает возможности для слежки и в конечном итоге может определить исход доступности какого-то ресурса в условиях сетевой фильтрации. Что же касается конфиденциальности самих подключений к ресурсам — протоколы конфиденциального DNS не берутся решать эту задачу, но могут служить ценными дополнениям к другим способам обеспечения конфиденциальности.
            +1

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


            DoT/DoH не препятствуют слежке, а просто подменяют одного шпиона другим, "которому можно доверять". :-D И, да, проблема ухудшения надёжности из-за централизации вполне реальна.


            В целом, все доступные в данный момент "расширения" DNS толком ничего реально полезного пользователю не дают. Лучшее, что сегодня можно сделать для защиты своего трафика, включая DNS — использовать VPN/Tor, и вручную отключать DoT/DoH как только их гугл с мозиллой начинают включать по умолчанию. Либо, если концепция шпиона "которому можно доверять" не вызывает отторжения — изменять настройки DoT/DoH с гугловых на мозилловские.


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

              +2
              DNSSEC не получил распространения потому, что не решает реальных проблем

              Он решает реальные проблемы, но не те, о которых вы пишете. Это про удостоверение записей DNS и, следовательно, невозможность (ок — сложность) из подмены. Иными словами, про гарантию, что данные, которые опубликовал в DNS владелец, не были изменены.
              Распространения же он не получил ввиду того, что сложен, замедляет процесс разрешения имён и, главное, в нём не заинтересованы крупные игроки. А для части из них, к примеру, коммерческих CA это вообще приговор, поскольку внедрение DNSSEC / DANE в популярный софт и, в первую очередь, браузеры, окончательно похоронило бы их бизнес.


              В отличие от DNSSEC — DoT (и DoH) это про защиту канала, то есть про приватность.
              Использование обоих инструментов совместно закрывает все актуальные проблемы нынешней DNS.

                0

                Я под "реальными" проблемами имел в виду те, с которыми реально сталкиваются обычные юзеры. Я более-менее отслеживаю новости по безопасности, и не припомню ни одной за последние несколько лет, в которой атака стала возможной именно благодаря отсутствию DNSSEC, а вот если бы он использовался — то всё, атака бы неизбежно провалилась. Можете накидать ссылок на такие случаи?


                DoT (и DoH) это про защиту канала, то есть про приватность

                А в чём конкретно защита? В том, что знать на какие сайты я хожу будет вместо одной мелкой организации (моего провайдера) другая крупная (гугл/cloudflare)? Защиту канала даёт VPN, и не только для DNS, а вообще для всего. Да, он её даёт только до ещё одного, сильно удалённого провайдера. Но этих удалённых "провайдеров" можно легко менять, в т.ч. автоматически (Tor). Как по мне — это заметно приватнее, чем отдать эти данные тем, кто и так уже слишком много о нас знает (считая и локального провайдера, и гугл).

                  0

                  Подмена ответов DNS известная как "DNS hijacking" известна и используется уже свыше двух десятков лет. Собственно, для её решения и разработали DNSSEC.
                  Защита в том, что отследить ваши DNS запросы становится крайне сложно. Эта информация даже сама по себе может быть полезна, не говоря уже о том если ею дополнить все остальные данные, получаемые крупными игроками.
                  Понятно, что защита канального уровня лучше, но она требует дополнительных усилий и тоже отнюдь не идеальна.

                    0
                    Некоторые провайдеры очень любят заворачивать DNS трафик на свои сервера и там их анализировать и/или изменять. Оно мне надо? Та же блокировка изначально была основана на подмене DNS ответов. DNSSEC решил бы эту проблему будь он пораспространеннее. Но мы так этого и не дождались. Зато DoT/DoH очень даже к месту пришлись и помимо достоверности (хотя она тут конечно не гарантируется) гарантируют, что ваш провайдер в запросы не заглянет.
              0
              … нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами
              В Windows как минимум с XP/2003 при отсутствии положительного ответа в течении секунды на запрос от основного DNS-сервера на предпочтительном интерфейсе опрашиваются основные DNS-сервера всех остальных интерфейсов.
              image
                  0
                  Проблема в том, что данный параметр как правило не используется по-умолчанию и о нём мало кто знает, а есть ещё L2TP, IPSec, Wireguard…
                +2
                www.simplednscrypt.org — для linux windows macos — завороачивает весь системный траф dns на автоматом выбрираемые сервера (большая пачка, и там не только google и cloudflare конечно) — как основной протокол dnscrypt который насколько я понимаю продуман немного лучше в плане защищенности в отличие от DoH. Для большей защищенности dnscrypt запросы можно отправить в тор. Как в прочем и весь остальной трафик.

                www.vpngate.net/en — отличный проект и неплохой помощник в деле отсечения длинных носов всех интересующихся.
                  0

                  Поделитесь кто чего включает/прописывает в OpenWRT, у кого есть роутеры.

                    0
                    На OpenWRT можно просто stubby установить, настроить его на DoH-сервер по своему предпочтению, а dnsmasq настроить на использование этого stubby.
                      0

                      DoT, он (пока) не умеет в DoH.

                        0
                        Да, пардон.
                      0
                      dnscrypt на openwrt qresolveblog.blogspot.com/2015/04/simple-tips-for-installing-dnscrypt-on.html — не свежий материал, думаю есть и поновее
                        0
                        dnscrypt-proxy + dnsmasq
                        –5

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

                          +2

                          Провайдеры и производители DPI начали переживать ?


                          Хорошо.

                          Only users with full accounts can post comments. Log in, please.