DNS-доступ под защитой: DoT и DoH

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

Технологии DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH) предназначены для защиты DNS-трафика (запросов и ответов) от перехвата и подмены. В базовых протоколах DNS исторически нет эффективных механизмов защиты, которые отвечали бы развитой модели угроз современного Интернета. DoT и DoH возникли как ответ на изменение ландшафта атак. Они определяют новый транспорт для передачи DNS-информации, то есть не изменяют саму систему доменных имён, но добавляют защищённый способ работы с DNS для приложений.

Аббревиатура DNS традиционно обозначает два фундаментальных для Интернета технологических механизма: систему доменных имён и службу (или сервис) доменных имён. Система доменных имён представляет собой распределённую базу данных с иерархической структурой, в которой хранятся пары «ключ – значение». Служба доменных имён — инструмент, выполняющий поиск в этой базе данных. Типичное применение DNS – это поиск IP-адреса, соответствующего имени сервера (имени хоста): здесь система доменных имён хранит пару «имя хоста – IP-адрес» (соответствующая структура называется «A-запись»), а служба выполняет рекурсивный опрос DNS-серверов и находит требуемый ответ (либо обнаруживает, что заданному имени хоста никакой IP-адрес в DNS не сопоставлен).

Каждый шаг сценария работы пользователя с вебом, как с основным пользовательским сервисом Интернета, задействует, прямо или косвенно, DNS. Для того, чтобы веб-браузер смог загрузить код разметки и отобразить веб-страницу по заданному адресу, часто требуются десятки DNS-запросов. Обычно эти запросы обслуживаются не клиентским компьютером, а внешними серверами. Поэтому возможны утечки информации о том, к каким веб-узлам подключался данный пользователь. Естественно, утечки касаются не только веб-протоколов. Более того, DNS позволяет реализовать сложные схемы идентификации пользователей, основанные на построении профилей активности. DNS-over-TLS и DNS-over-HTTPS делают некоторые из каналов таких утечек неэффективными, повышая тем самым «приватность пользователя». Это одна из решаемых данными технологиями задач, но не единственная.

Утечки информации

Для защиты информации и в DoT, и в DoH используют одну и ту же основу - TLS (Transport Layer Security). TLS позволяет построить защищённый от прослушивания и подмены канал обмена информацией между узлами, а также аутентифицировать узлы. Но последний элемент - аутентификация узлов - применяется с ограничениями.

Вернёмся к поиску в DNS и возможным утечкам информации, от которых как раз защищает TLS. Процедура поиска основана на рекурсивном опросе серверов, поддерживающих доменные зоны различного уровня. Узел, производящий поиск какой-либо DNS-записи для заданного имени, обращается сначала к корневым серверам глобальной DNS, потом, если требуемый ответ не получен, к серверам, стоящим на следующем уровне иерархии (например, серверы зоны .RU), и так далее — этот процесс хорошо известен всякому, кто интересовался интернет-технологиями. Как мы уже заметили выше, рекурсивный опрос редко выполняется непосредственно на стороне компьютера пользователя. Реализация данной функции — прерогатива специального сервера, IP-адрес которого назначается сетевой конфигурацией операционной системы. Это будет либо сервер, предоставляемый провайдером доступа, либо один из узлов хорошо известных публичных сервисов DNS, которые сейчас стали довольно популярны.

Системный резолвер, работающий на клиенте (компьютере пользователя), только перенаправляет запросы внешнему рекурсивному резолверу. В классическом варианте DNS-трафик не зашифрован. Это означает, что, как минимум, провайдер доступа может просматривать DNS-запросы и DNS-ответы в обоих случаях: и при использовании рекурсивного резолвера провайдера, и если используется внешний, незащищённый, DNS-сервер. При этом в первом случае, когда DNS-резолвер принадлежит провайдеру доступа (или оператору связи, что не так важно), запросы доступны провайдеру для анализа непосредственно на самом резолвере. Очевидно, никакая защита канала между системным резолвером пользователя и рекурсивным резолвером не может защитить DNS-запросы (и ответы) от просмотра администратором рекурсивного резолвера. Если пользователь настроил внешний DNS-сервис, - то есть сервис, не контролируемый провайдером доступа, - то для просмотра клиентских DNS-запросов провайдеру придётся анализировать непосредственно сетевой трафик (на уровне протоколов UDP и TCP). Этот метод хоть и сложнее анализа на уровне DNS-резолвера, но всё равно доступен всякому провайдеру.

Может показаться, что провайдер доступа и так знает по IP-адресам все узлы, к которым обращается пользователь, а поэтому просмотр DNS-запросов не даёт никакой новой информации. Это не так. Дело в том, что DNS предоставляет информацию другого уровня — уровня приложений, поэтому позволяет, в том числе, собирать данные, принципиально недоступные на более низком уровне. Прежде всего, DNS раскрывает имена узлов, а это совсем не то же самое, что IP-адреса. Часть DNS-трафика относится к различным вспомогательным протоколам (например, каталогизация на стороне приложения адресов доступных узлов, обращения к которым по IP может и не происходить). DNS играет важную служебную роль во многих протоколах, раскрывая их специфические характеристики (примеры здесь разнообразны: инструменты для майнинга криптовалют, мессенджеры, системы телеконференций, системы IP-телефонии и так далее).

Нередко информация о DNS-активности утекает даже при использовании VPN (Virtual Private Network — виртуальная частная сеть), если в защищённую виртуальную сеть направлен только основной IP-трафик, а обработка DNS оставлена резолверу провайдера доступа (согласно системной конфигурации).

В случае HTTPS для веба, работающего поверх TLS, имя сервера, с которым соединяется программа-клиент (браузер), обычно передаётся в открытом виде — то есть, оно может быть извлечено из TCP-потока на промежуточном узле. Однако существует технология (ESNI, а точнее – современная её версия, ECH – Encrypted Client Hello), которая позволяет клиенту зашифровать имя сервера в TLS. Соответственно, без DNS-трафика промежуточные узлы провайдера увидят только IP-адрес веб-узла, а один IP-адрес может соответствовать нескольким тысячам веб-узлов.

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

DoH и DoT зашифровывают трафик, исключая только что описанную утечку. Естественно, для защиты клиентского DNS-трафика данные технологии должны внедряться на пути от клиента до рекурсивного резолвера (это минимум — см. ниже). Типовая конфигурация сейчас подразумевает, что поддержка DoH включена прямо в браузере, а в качестве рекурсивного резолвера сконфигурирован тот или иной внешний DNS-сервис. Например, для браузера Firefox это может быть сервис Cloudflare, который рекомендует Mozilla (и не только рекомендует, но может и включить по умолчанию). Ключевой момент такой конфигурации, – обозначающий, ни много ни мало, смену парадигмы, – состоит в том, что приложение (браузер) работает с DNS, минуя и локальную системную службу, и резолвер провайдера доступа. Браузер по защищённому каналу обращается к другому приложению, работающему на внешнем сервере, и доверяет именно ему в поиске DNS-информации.

Протокольные надстройки

С точки зрения стороны, анализирующей трафик, ситуация выглядит следующим образом: вместо DNS-запросов и DNS-ответов обнаруживается только факт установления TLS-соединения между клиентом и сервером с некоторым IP-адресом. Так как DNS работает внутри TLS-соединения, а оно зашифровано, то никаких сведений об использовании DNS анализатор трафика не получает. Однако, так как речь идёт только о «последней миле», то есть о канале от клиента до рекурсивного резолвера, оператор резолвера видит всю DNS-активность своего клиента. Но это, обычно, внешний резолвер, недоступный провайдеру доступа. DNS-over-HTTPS использует для отправки запросов и получения ответов сервера протокол HTTP (рекомендован HTTP/2). Надо отметить, что это довольно серьёзная «надстройка» для DNS.

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

А вот реализация DoH требует и HTTP/2, и TLS, и TCP, и всё это не отменяет DNS, хоть последний протокол и преломляется существенно в ходе приспособления к HTTP. В сравнении с UDP-транспортом увеличение сложности тут огромное. А обусловлен такой выбор тем, что готовая поддержка HTTPS распространена как на клиентах, так и на серверах. В более важном здесь случае с клиентом (речь про браузеры), где, по понятным причинам, обязательно имеется интерфейс доступа к HTTP «на уровне исходных данных», реализация «заворачивания» DNS в HTTPS не требует разработки объёмных дополнительных модулей. (На стороне сервера DoH сейчас поддерживается основными пакетами, например, Unbound и PowerDNS.)

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

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

Использование TLS позволяет побороть и другую угрозу, активную. В классическом случае локальный узел, отправивший запрос внешнему DNS-резолверу, не может определить, кто именно прислал ответ. Это касается и UDP, и, в меньшей степени, TCP. Дело в том, что ответить вместо узла с заданным IP-адресом может любой промежуточный узел. Это не составляет большого труда, хотя и требует вмешательства в работу сетевого оборудования. Пакет, отправленный к (условному) резолверу по адресу 1.1.1.1, до «подлинного» обладателя этого IP-адреса не дойдёт, а клиент получит ответ от близкого к нему промежуточного узла. И, в случае DNS-запроса, ответ этот может быть произвольным. TLS позволяет клиенту аутентифицировать сервер (и наоборот, но аутентификация клиента используется редко), после чего продолжать работу только с узлом, который смог подтвердить свою подлинность. Для практических приложений, в случае DoH, такая проверка скорее обязательна, а для DoT в современном состоянии клиент на практике может легко пропустить шаг аутентификации сервера.

Технологический ландшафт и фильтрация

Для DNS существует и более старая технология защиты адресной информации от подмены — DNSSEC. Нужно заметить, что ни DoT, ни DoH не отменяют DNSSEC, так как работают на совсем другом уровне: DoT/DoH защищают DNS-трафик только в момент передачи через промежуточные узлы; DNSSEC защищает при помощи механизма электронной подписи подлинность и неизменность самой информации DNS. При этом DNSSEC никак не скрывает запросы или ответы серверов: данные передаются в открытом виде. Однако, если клиент умеет проверять подписи DNSSEC и знает корневой открытый ключ глобальной DNS, то для такого клиента не имеет значения, как именно получены DNS-данные, от доверенного узла или нет, — валидная подпись гарантирует, что данные не были изменены и сформированы авторизованным источником. А вот если клиент подключился по DoT или DoH к злонамеренному DNS-резолверу, то эти технологии никак не помогут клиенту отличить верный DNS-ответ, присланный резолвером, от поддельного, который этот же резолвер сгенерировал, поскольку они гарантируют только подлинность узла-резолвера, но не DNS-информации. Иными словами, DoT/DoH и DNSSEC — совершенно разные технологии, которые могут эффективно дополнить друг друга.

Ещё одной важной отличительной чертой DoH и DoT при применении между клиентом и резолвером является номер используемого сервером порта TCP. Как известно, TCP-соединения, помимо прочей информации, характеризуются номерами портов. Есть так называемые «хорошо известные» номера, которые соответствуют конкретным типам сервисов (серверных служб). Так, за HTTP закреплён номер 80. А за HTTPS — номер 443. DNS соответствует номер порта назначения 53 (и для UDP, и для TCP). Чтобы различать классический вариант DNS и DoT, для последнего выделен номер порта 853. Номер уникальный, а это означает, что соединения DoT можно фильтровать на уровне сетевого транспорта просто по номеру порта и надеяться, что при этом у пользователя не сломается вообще всё, а только лишь исчезнет возможность использовать внешний сервис DNS-резолвера.

Ситуация с DoH совсем другая: предполагается, что данный протокол работает по HTTPS на номере порта 443, то есть точно так же, как и привычный доступ к веб-узлам по HTTPS. Если же кто-то решится заблокировать весь трафик по номеру 443, то таким образом этот кто-то отключит и все значимые веб-узлы, для которых HTTPS давно является основным протоколом (в двадцатых годах двадцать первого века веб-сайт не должен использовать незащищённый протокол HTTP, за исключением, быть может, весьма экзотических случаев обратной совместимости). Несомненно, дополнительные затруднения, связанные с тем, что отличить DNS внутри HTTPS от «обычного» HTTPS доставки веб-страниц сложно, могут составить ценное преимущество. Или составить критический недостаток, который испортит всё дело. Тут, как иногда говорят матёрые адвокаты, многое «зависит от того, на чьей стороне выступаем».

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

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

Естественно, никто не мешает настроить поддержку DoT/DoH на внутреннем DNS-резолвере, будь то корпоративный резолвер или резолвер провайдера доступа. В таком случае останется доступным даже пассивный анализ трафика. Дело в том, что оператор резолвера может выгружать на инспектирующий узел секретные ключи TLS, а это позволяет расшифровывать трафик. Но данный ход не отменяет возможности использования других резолверов и не упрощает обнаружение факта такого использования.

Сложившаяся практика внедрения DoH/DoT (в особенности — DoH) очень хорошо показывает, что хоть сами технологии и не подразумевают какой-то дополнительной централизации, эта централизация всё же происходит: повсеместно используют DNS-сервисы лишь от нескольких глобальных провайдеров (прежде всего, Cloudflare и Google), которые поддерживают работу через DNS-over-HTTPS. Более того, эта технология, скорее всего, достаточно быстро разовьётся в конфигурацию, когда браузер будет получать всю нужную вспомогательную информацию по HTTPS из единого источника. Под «всей нужной» информацией здесь подразумеваются и DNS, и, собственно, HTTP, и различные дополнительные ресурсы, требуемые для извлечения и отображения веб-страниц: адреса CDN (Content Delivery Network – служба доставки контента), криптографические ключи и т. д. То есть возникнет новый протокол (уже не как DoH, а под другим названием) обнаружения параметров доступа к серверным приложениям. И этот протокол будет работать через некоторую единую «точку входа».Сразу после старта браузер будет подключаться к указанному в настройках узлу, – естественно, проверив подлинность, – получать текущие параметры DNS, а также списки резервных узлов доступа, перечни TLS-сертификатов, коллекции криптографических ключей, описания и адреса CDN, прокси-серверов, различных «веб-ускорителей» и, вероятно, даже доступ к VPN. В сформированной среде браузер, как приложение, будет взаимодействовать с другими доверенными приложениями на различных серверах. Для стороны, пытающейся фильтровать трафик, либо собирать метаинформацию об активности пользователя, весь трафик различных пользователей будет выглядеть одинаково, отличаясь лишь IP-адресами узлов, да и то, далеко не так сильно, как сейчас. Попытка блокирования доступа к узлам по IP-адресу приведёт либо к полной неработоспособности для пользователя непредсказуемого по составу набора приложений, либо к простой замене IP-адресов для преодоления блокировки: новые адреса будут переданы (например) браузеру в рамках только что описанного протокола обнаружения.

Если сложить все технические особенности вместе, то окажется, что технологии DNS-over-TLS и, особенно, DNS-over-HTTPS являются предвестниками новой парадигмы в области практической информационной безопасности, когда механизмы доверия выстраиваются не на уровне сетевых узлов, даже не на уровне операционной системы, а на уровне конкретных приложений. Одним из существенных факторов такого перехода, несомненно, является реакция на глобальное движение в сторону сегментации Сети. Конечно, расщепление некогда плоского Интернета на логические области уровня приложений, каждый из которых контролируется некоторой корпорацией, -тоже сегментация. Но этот, вполне конкретный, процесс является попыткой использовать владение богатейшим технологическим инструментарием для того, чтобы упредить наметившиеся тенденции обособления сетей. Эта попытка имеет большие шансы стать успешной.