DoH, или DNS, похожий на веб

Андрей Робачевский

Защита личных данных и конфиденциальности информации в Интернете является важной и в то же время сложной задачей. Но кто бы мог подумать, что разработчики, пользователи и операторы DNS – системы трансляции имен в Интернете – будут озабочены этой проблемой? Шифрование данных – одно из стандартных решений конфиденциальности, но как и что шифровать в DNS? В этой статье речь пойдет о новом протоколе защиты данных и особенно метаданных DNS – «DNS over HTTPS». Несмотря на то, что стандарту меньше года, он уже прошел интенсивную стадию экспериментирования и активно внедряется ведущими разработчиками браузеров. До сих пор не утихают споры, что означает внедрение централизованного DoH для безопасности и конфиденциальности данных пользователей. Но может быть DoH – это знак нового эволюционного витка развития DNS и Интернета в целом?

Все началось с разоблачений Эдварда Сноудена. IETF встал на тропу войны и объявил всеобщий мониторинг трафика в Интернете ничем иным как технической атакой¹. А раз так, то борьба с ней должна осуществляться техническими средствами, путем усиления безопасности протоколов IETF. Основным методом для этого явилось шифрование.

Наиболее заметен прогресс в области шифрования веб-трафика. Если в начале 2014 года (когда был опубликован RFC7258) процент трафика HTTPS к сайтам Google составлял около 50%, то сегодня он равен 94%. Процент загруженных страниц с использованием HTTPS по различным оценкам сегодня составляет 80-90%² (см. рис.1).

Источник: https://letsencrypt.org/stats/#percent-pageloads.

Само шифрование также было усилено – TLS 1.3, являющийся основой различных протоколов приложений, как, например, тот же HTTPS, получил возможность использования эфемерных сеансовых ключей, существенно затрудняющую мониторинг трафика не только в большом Интернете, но и в корпоративных сетях. В отношении последних шифрование и, в частности, новые протоколы, такие как TLS 1.3., усложнили, а подчас сделали невозможным использование решений сетевой безопасности – экранов безопасности (firewalls) и систем обнаружения вторжений (Intrusion Detection Systems, IDS). См., например, «TLS 1.3 Impact on Network-Based Security»³.

Несомненно, развитие в этом направлении сделало использование Интернета более защищенным, как в плане целостности передаваемых данных, так и в их конфиденциальности. Правда, остаются так называемые метаданные, например, IP-адреса отправителя и получателя, тип используемого приложения (порт), а также некоторая другая информация, например, SNI (Server Name Indication), указывающая на имя сервера, с которым устанавливается связь. В отношении SNI в IETF ведется работа по шифрованию и этого поля, т.н. Encrypted SNI⁴.

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

Проблема с конфиденциальностью в DNS заключается в том, что эта система представляет собой распределенную базу данных, отдельные компоненты которой обслуживаются различными организациями. Поэтому для получения интересующего нас ответа, например, IP-адреса сервера www.example.com, наш запрос будет обрабатываться несколькими организациями, не имеющими отношения к интересующему нас ресурсу. В наиболее часто применяемой модели одной из таких организаций будет оператор рекурсивного резолвера, чаще всего Интернет сервис-провайдер пользователя, а другими – операторы корневых серверов (в общем случае запрос начинается именно здесь) и оператор домена .com. Добавим к этому, что конфиденциальность данных до недавнего времени не считалась проблемой – в конце концов, вся эта информация является публично доступной – чтобы представить масштаб задачи.

Ну если мы не можем зашифровать данные самого DNS⁵, можно ли хотя бы защитить от посторонних глаз обмен информацией между пользователем и резолвером и между резолвером и авторитетными серверами? Первая задача кажется вполне решаемой, и именно с этого IETF начал свою работу в рамках рабочей группы DPRIV.

Одним из решений, разработанных этой группой, явился DoT, или DNS over TLS. Этот протокол документирован в RFC7858⁶ и как подсказывает название, использует протокол безопасности транспортного уровня (TLS) для шифрования связи между клиентом и сервером, а также для аутентификации сервера. Подобно тому, как TLS используется для защиты сеансов HTTP и обеспечения некоторой гарантии того, что сервер авторизован владельцем размещенного на нем информационного ресурса, этот протокол также можно использовать в контексте DNS между пользователем (т.н. резолвером-заглушки, stub resolver) и выбранным им рекурсивным резолвером.

Хотя DoT сегодня реализован в программном обеспечении таких известных резолверов, как Unbound и Knot, вопрос внедрения остается проблемой. Немногие операторы резолверов предлагают эту возможность, да и поддержка и настройка DoT в клиентском ПО, особенно на мобильных устройствах, оставляет желать лучшего.

Как обычно, даже если решение проблемы существует, его внедрение представляет основную задачу. Особенно, если это требует совместных действий независимых сторон – операторов резолверов и пользователей с их клиентским ПО, – что является типичным в Интернете.

Однако, говоря о клиентском ПО, задумаемся – какое наиболее используемое приложение в Интернете сегодня? Конечно же веб, и даже если некоторые приложения маскируются как самостоятельные единицы, за кулисами они используют веб-протокол HTTPS. А раз HTTPS самый распространенный протокол приложений в Интернете, почему бы не использовать именно его для шифрования трафика DNS?

Ко всему прочему, используя HTTPS, мы получаем ряд преимуществ: этот протокол очень редко подлежит блокировке и поддерживает такие функции, как «кэширование, перенаправление, проксирование, аутентификация и сжатие».

И появился DoH – DNS over HTTPS.

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

DoH⁷ позволяет клиенту инкапсулировать обмен сообщениями DNS в протокол HTTPS. Существует два возможных способа отправки данных – через запрос POST или GET. У каждого есть свои особенности и преимущества.

При отправлении запроса методом POST тип передаваемых данных (MIME заголовок Content-Type) определен как application/dns-message, а сам запрос передается без какого-либо кодирования – в «сыром» двоичном виде, начиная с заголовка DNS. Объем передаваемых данных в случае POST несколько меньше.

Метод GET передает запрос DNS с использованием параметра ?dns= с последующим запросом в кодировке Base64Url⁸. Этот метод лучше работает с кэшированием, поэтому можно рассчитывать на меньшую задержку получения ответа, хотя размер самого запроса больше, чем в случае POST.

Ответ всегда приходит с заголовком application/dnsmessage, когда данные DNS инкапсулированы в «сыром» виде.

Стоит отметить, что клиенту DoH придется иметь дело с двумя группами кодов успеха или неудачи операции – собственно DNS и HTTP. Так, например, клиент может получить формально правильный ответ (код HTTP «200 OK»), в то время как ответ DNS будет содержать код SERVFAIL или NXDOMAIN.

Сценарии внедрения DoH

Нетрудно заметить, что как протокол DoH не многим отличается от DoT. Также, представляется разумным использовать современные методы шифрования для защиты трафика DNS. Хотя DNS в силу своей архитектуры не предусматривает сквозную защиту (никто не предполагал, что она потребуется), защита канала между клиентом (например, резолвер-заглушка пользовательского компьютера) позволяет защитить от целого класса MITM-атак, а использование транспортного протокола TCP избавит нас от зловредных отражающих атак с усилением, которые используют открытые резолверы.

Что касается приватности, то тут есть оговорки. Начнем с того, что внедрение этого протокола для обмена данными между резолвером и авторитетными серверами проблематично как с точки зрения аутентификации, так и с точки зрения производительности. Поэтому стандарт DoH сфокусирован на «обмене данными между клиентами DNS (такими как резолверы-заглушки операционной системы) и рекурсивными резолверами». Далее, одним из основных сценариев применения DoH является «предотвращение вмешательства промежуточных устройств в обмен данными DNS». Но в большинстве случаев путь между пользователем и резолвером, включая и сам резолвер, полностью контролируется сервис-провайдером. Так что в этом варианте особых преимуществ пользователь не получает.

Совсем по-другому выглядит ситуация, когда в качестве резолвера используются «публичные» резолверы, такие как Public Google DNS (8.8.8.8) или Cloudflare (1.1.1.1). Использование такого резолвера может быть решением пользователя, но некоторые сервис-провайдеры используют их для полного аутсорсинга услуг DNS. В этом случае защита от посторонних глаз безусловно имеет смысл – DNS очень «разговорчивый» протокол и его прослушивание может рассказать много о клиенте.

Привлекательность этого сценария для разработчиков клиентских приложений, например, браузеров, заключается в том, что можно выбрать установку по умолчанию и взять трансляцию имен в свои руки. А заодно и заботу о приватности пользователей (см. рис. 2).  Однако здесь нас встречают несколько проблем.

Технические и бизнес-риски централизованного DNS

Интернет-драфт «Проблемы и риски реализации централизованного DNS через HTTPS (DoH)»⁹ обсуждает технические и бизнес-риски, связанные с централизованной схемой внедрения DoH. Перечислим некоторые из них.

Ухудшение детектирования угроз безопасности:

Некоторые пользователи могут потерять способность использовать DNS-блокировки, которые являются одним из основных способов защиты сети и ее пользователей от вредоносных программ, фишинга, спама, DDoS-атак и т.д.

Политика безопасности многих сетей, в том числе и сетей доступа, сетей предприятий, школ и других публичных заведений, включает в себя мониторинг и защиту безопасности сети и устройств в этой сети. Одним из широко распространенных методов осуществления этой политики является использование DNS для мониторинга, исправления и/или предотвращения заражения вредоносным ПО или других проблем безопасности.

Например, сетевые операторы могут применять этот метод (отдельно или совокупно с более детальным анализом трафика) для блокировки доступа к запрещенному контенту или вредоносным и фишинговым веб-сайтам. Так, многие сети проверяют, не присутствует ли запрашиваемое доменное имя в списках известных вредоносных команд и командных центров ботнетов. В случае совпадения владелец устройства или администратор локальной сети могут быть уведомлены о потенциальном заражении вредоносным ПО. В другом варианте резолвер перезаписывает ответ на запрос такого доменного имени, предоставляя адрес сервера, предупреждающего конечного пользователя о риске вредоносного ПО, или же предоставляя ответ NXDOMAIN – несуществующее имя – для прекращения поиска. Очевидно, что эта функциональность не будет работать, если DNS-запросы обходят резолверы, которые выполняют эту функцию, в случае централизованного внедрения DoH. Таким образом, централизованный DoH может создать «слепые» зоны в этой критической области противодействия угрозам безопасности.

Потеря видимости угроз может привести к использованию DoH в качестве нового и не обнаруживаемого вредоносного канала управления и контроля. Одним из примеров является DoHC2¹⁰. В результате, сам DoH иногда может рассматриваться как угроза безопасности, учитывая его возможное использование в качестве скрытого канала управления вредоносными программами и контроля.

Нарушение функций портала доступа в Интернет (captive portal)

Многие сети доступа используют различные порталы, основанные на DNS, например, для регистрации устройства для доступа в Интернет в публичных (например, беспроводные сети в кампусах, аэропортах и кафе) и корпоративных сетях или восстановления доступа после неуплаты. Централизованный DoH нарушает работу таких систем, поскольку браузер переопределяет специально назначенные адреса DNS-резолверов, реализующих эти функции, и вместо этого пытается использовать централизованный резолвер DoH. Хотя новые стандарты в рабочей группе IETF CAPPORT¹¹ могут избежать этого в будущем, стандарты CAPPORT все еще разрабатываются и широко не используются.

Потеря родительского контроля или других элементов управления контентом

Аналогично использованию DNS в локальных сетях для мониторинга и защиты от угроз безопасности, DNS часто используется для реализации элементов управления контентом, например, таких как родительский контроль. С помощью этих элементов управления родитель может настроить службу в своей домашней сети, чтобы дети не могли получить доступ к нежелательному или другому запрещенному контенту. Например, родители могут настроить политику, чтобы запретить своим детям-дошкольникам доступ к любым сайтам, связанным с социальными медиа, азартными играми, наркотиками, порнографией и так далее. Такие сервисы часто предоставляются сетями доступа или доступны по подписке и пользуются большой популярностью, особенно потому, что они могут работать с разными типами устройств (например, ПК и мобильные устройства) и экосистемами устройств (например, Android и Apple), программным обеспечением (например, Mac и Windows) и экосистемами платформ (например, Google, Apple и Amazon).

Как и в примере с вредоносным ПО, это обычно реализуется посредством сопоставления и перезаписи ответов DNS, когда конечному пользователю предоставляется либо перенаправление на страницу блокировки контента, либо получение ответа несуществующего имени NXDOMAIN. Эта функциональность не будет работать, если DNS-запросы обходят серверы, которые выполняют эту функцию, для централизованных резолверов DoH. Даже если поставщик централизованного DoH и предлагает подобные услуги, их характеристики могут не соответствовать требованиям пользователя.

Проблемы с разделенным DNS

Разделенный DNS, или DNS с «расщепленным горизонтом»¹² – это система, в которой внутренние и внешние сети обслуживаются различными DNS-серверами. Это чаще всего используется в корпоративных, образовательных и государственных сетях в качестве средства управления безопасностью и конфиденциальностью. На практике это означает, что существуют имена, которые транслируются только в адреса внутренней сети, или имена, которые транслируются в адреса внутренних серверов для пользователей внутренней сети и в адреса общедоступных серверов для пользователей за пределами сети. Например, предприятие может иметь внутреннюю службу с именем «Система учета», доступную в Интернете через https:// accounting-system или https://accounting- system.example. com и подключенную через внутренний не маршрутизируемый RFC1918 IPv4-адрес, такой как 192.168.1.77. Эти доменные имена поддерживаются только в локальных резолверах и не могут быть транслированы с использованием авторитетной DNS-инфраструктуры Интернета. Эти имена больше не будут транслироваться на основе внешней реализации DoH.

Утечка корпоративных данных

При использовании разделенных имен DNS, как отмечено в приведенном выше примере для пользователя в корпоративной сети, пытающегося подключиться к хосту по адресу https://accounting-system.example.com, поиск с централизованным резолвером DoH будет обычно терпеть неудачу (NXDOMAIN). Но поскольку внутреннее имя было отправлено в централизованный распознаватель DoH, это частное имя «просочилось» за пределы локальной сети или сети предприятия, делая корпоративную сеть более уязвимой с точки зрения компьютерной безопасности. Аналогично, поиск обратных DNS-имен (in-addr.arpa) также приведет к утечке частных IP-адресов. Утечка данных IP-адреса может произойти независимо от того, используется ли разделенный DNS.

Один из основных пропонентов DoH – некоммерческая компания Mozilla, разработчик популярного браузера Firefox, работает над решениями, которые позволят уменьшить, если не свести на нет негативные последствия DoH, которые мы обсудили. Например, проверки, включен ли родительский контроль. Для этого Firefox пытается транслировать специальное доменное имя, которое занесено в «черные списки». В случае обнаружения блокировки Firefox автоматически отключит DoH и станет использовать DNS, предоставляемый операционной системой пользователя. Подобным образом определяются конфигурации «расщепленного горизонта». Более подробно с этими методами можно ознакомиться на сайте Mozilla¹³.

Вопросы приватност

Централизованные решения внедрения DoH вызывают также озабоченность в области защиты личных данных и приватности. Иронично, что шифрование передачи данных DNS и, в частности, DoH, призваны усилить защиту личных данных, но иногда лекарство может быть хуже болезни.

Представьте, что все ваши перемещения в Интернете фиксируются одним провайдером DoH. Пользуетесь ли вы Интернетом дома, на работе, в кафе, на компьютере или смартфоне, все запросы DNS, а значит, и ваши действия, регистрируются в одном месте. Это, конечно, не означает, что провайдер DoH непременно станет использовать эту информацию, но кто оценивает эти риски и выбирает подходящего провайдера DoH? По всей видимости – это сами браузеры. Для минимизации рисков, например, Mozilla создала специальную программу Mozilla Trusted Recursive Resolver (TRR), содержащую минимальный набор требований политики, которым должен соответствовать оператор, чтобы считаться потенциальным партнером программы. Требования включают конкретное описание политики сбора и хранения данных, прозрачности и блокирования¹⁴.

Вопрос относительно преимуществ и недостатков использования централизованного DoH также связан с конкретной моделью угроз. Нет никаких сомнений, что централизованный DoH может быть полезен в некоторых сетях. Например, при использовании Интернета в кафе Public DNS Google, скорее всего, лучший выбор, чем местный резолвер. Или тот факт, что многие пользователи в США рассматривают своих интернет-провайдеров как угрозу, поскольку известно, что эти интернет-провайдеры напрямую монетизируют DNS-запросы и продают их рекламодателям. Обратное верно в отношении Европейского Союза. Благодаря GDPR, интернет-провайдеры в ЕС жестко ограничены в том, что они могут делать с данными DNS, и поэтому в девяти случаях из десяти провайдер интернет-доступа, вероятно, является лучшим выбором с точки зрения конфиденциальности, чем любой облачный DNS-резолвер. Другими словами, какой резолвер использовать, зависит от конкретной ситуации.

Проблема в том, что пользователь весьма далек от настроек такого типа – многие не знают, что такое DNS, не говоря уже о конфигурации конкретного резолвера. Поэтому настройки по умолчанию в большинстве случаев вряд ли будут изменены. Сегодня для того, чтобы включить DoH в Firefox, необходимо изменить установку, но Mozilla уже сообщила о планах конфигурации DoH по умолчанию для американских пользователей уже в конце сентября 2019 (см. рис.3).

В заключение хочется заметить, что централизованный DNS не является порождением DoH. Публичные резолверы, такие как Public DNS компании Google, OpenDNS (Cisco), 1.1.1.1 (Cloudflare), Quad9, существуют уже не первый год и активно используются. Согласно измерениям APNIC Labs чуть более одного из шести пользователей используют один из публичных резолверов в качестве основного ¹⁵. DoH усиливает эту тенденцию и, учитывая его тесную интеграцию с поставщиками контента, это, может быть, обозначает новый эволюционный виток развития DNS и Интернета в целом.

Ссылки

1. RFC7258 “Pervasive Monitoring Is an Attack”;
2. см. https://letsencrypt.org/stats/#percent-pageloads, https://transparencyreport.google.com/https/overviewж
3. https://datatracker.ietf.org/doc/draft-camwinget-tls-usecasesж
4. “Encrypted Server Name Indication for TLS 1.3”;
5. Хотя сами данные DNS шифровать не имеет смысла, частичную защиту приватности можно осуществить путем т.н. минимизации данных запроса. Обычно один и тот же вопрос (например, «каков IP-адрес www.example.com?») отправляется всем участникам процесса разрешения имени. Хотя лучше было бы спрашивать корневые серверы о серверах .com, а тех, в свою очередь, о серверах, обслуживающих домен example.com. И только последних – об адресе www.example.com. Этот метод описан в экспериментальном RFC 7816 “DNS Query Name Minimisation to Improve Privacy”ж
6. RFC7858 “Specification for DNS over Transport Layer Security (TLS)”
7. RFC8484 “DNS Queries over HTTPS (DoH)”ж
8. RFC4648 “The Base16, Base32, and Base64 Data Encodings”ж
9. “Centralized DNS over HTTPS (DoH) Implementation Issues and Risks”;
10. https://github.com/SpiderLabs/DoHC2
11. https://datatracker.ietf.org/wg/capport/about/
12. см. RFC8499 “DNS Terminology”ж
13. https://blog.mozilla.org/futurereleases/2019/09/06/whatsnext-in-making-dns-over-https-the-default/  
14. https://wiki.mozilla.org/Security/DOH-resolver-policy
15. “DNS resolver centrality”ж