DNS-over-TLS vs. DNS-over-HTTPS
Настраиваю свой DNS-сервер, выбрал Pi-hole и публичный DNS от Cloudflare. Поскольку хочу DNS-запросы зашифровать, хочу использовать DoT или DoH. Что используете вы и почему? Какие лично для вас преимущества у того или другого варианта? Есть ли тут параноики, использующие DNS-over-Tor или ещё более извращённые варианты?
CYB3R ★★★★★
02.07.21 12:56:48 MSK
Пускаю через Tor, работает шикарно.
Prosto_user ★★★
( 02.07.21 13:04:51 MSK )
Я использую dnscrypt. Из предложенных технически я — за DoT(меньше накладных расходов), идеологически — лучше DoH(меньше вероятность что порубят на файрволах, в том числе и «товарищи» из РКН)
Pinkbyte ★★★★★
( 02.07.21 14:00:04 MSK )
Последнее исправление: Pinkbyte 02.07.21 14:00:23 MSK (всего исправлений: 1)
В роутере настроил DoT и DoH. Что из них для конкретного запроса отрабатывает быстрее я хз.
anonymous
( 02.07.21 14:15:42 MSK )
Везде сейчас используют DoH, остальное можно считать неактуальным.
anonymous
( 02.07.21 14:37:43 MSK )
Использую DoT. HTTP в таком приложении имеет изрядный оверхед и его стоит использовать только понимая, зачем именно: например в сетях, где закрыты другие порты/сервисы или необходимо однозначно ловить ошибки на уровне приложения.
С DNS от Cloudflare есть важный нюанс. DoT и DoH работают поверх TCP, а сервера one.one.one.one очень быстро рвут соединения. В результате практически каждый DNS-запрос претворятся TCP-хендшейком со своей задержкой на разговоры о погоде.
У меня через DNS от Google, где нормальные keepalive, среднее время ответа на запрос в полтора раза меньше, чем с Cloudflare. Хотя время пинга до 8.8.8.8 больше в два раза.
anonymous
( 02.07.21 14:48:57 MSK )
Поставил на openWRT роутере Stubby. От использует несколько серваков для DNS-over-TLS. Никаких проблем нет.
Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)
Контролируете ли вы свой DNS трафик? Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS.
Хорошим обзором рисков, которые приносит DNS является презентация Verisign на конференции Infosecurity.
Выводы исследования
31% обследованных классов программ-вымогателей использовали DNS для обмена ключами.
Проблема серьезная. По данным исследовательской лаборатории Palo Alto Networks Unit 42, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.
Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например, заплатили 10 миллионов долларов.
При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.
Что такое зашифрованный DNS?
Что такое DNS
Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адрес www.paloaltonetworks.com ) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.
Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.
За последние несколько лет были внедрены два протокола шифрования DNS:
- DNS-over-HTTPS (DoH)
- DNS-over-TLS (DoT)
Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата. и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.
Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.
DNS over HTTPS (DoH)
DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы «смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении», «затруднить анализ трафика DNS» и, таким образом, обойти меры корпоративного контроля ( RFC 8484 DoH, раздел 8.1 ). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.
Риски, связанные с DoH
Если вы не можете отличить обычный HTTPS-трафик от запросов DoH, то приложения внутри вашей организации могут (и будут) обходить локальные настройки DNS, перенаправляя запросы на сторонние сервера отвечающие на запросы DoH, что обходит любой мониторинг, то есть уничтожает возможность контроля за DNS трафиком. В идеале вы должны контролировать DoH используя функции расшифрования HTTPS.
И Google, и Mozilla реализовали возможности DoH в последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS. Microsoft также разрабатывает планы по интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи: PsiXBot теперь использует Google DoH , PsiXBot продолжает развиваться с обновленной инфраструктурой DNS и анализ бэкдора Godlua .) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.
Обеспечение видимости и контроля трафика DoH
В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).
Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласно руководству по лучшим методам расшифровки.
Во-вторых, создайте правило для трафика приложения «dns-over-https», как показано ниже:
В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия «запретить» к идентификатору приложения «dns-over-https», но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см. Applipedia от Palo Alto Networks и выполните поиск по фразе «dns-over-https»).
DNS over TLS (DoT)
В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует специальный порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS ( RFC 7858 , Раздел 3.1 ).
Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 ( RFC 7858, раздел 6 ). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.
Риски, связанные с DoT
Google реализовал DoT в своем клиенте Android 9 Pie и более поздних версиях , при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.
Обеспечение видимости и контроля трафика DoT
В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:
- Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подписку Palo Alto Networks DNS Security для контроля DGA доменов или уже имеющийся DNS Sinkholing и anti-spyware.
- В качестве альтернативы можно полностью заблокировать движком App-ID трафик ‘dns-over-tls’ через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение ‘dns-over-tls’ или трафик через порт 853).
DOT и DOH, и DNS, как вектор атаки
Последнее время в новостных лентах все чаще появляются термины DOT и DOH. На прошедшей неделе компания Microsoft анонсировала интеграцию DOH в ОС Windows 10, а в дальнейшем и DOT. Ранее Mozilla и Chrome уже заявляли об интеграции этих протоколов в своих web-браузерах. Android включил нативную поддержку DOT/DOH, а ранее была возможность работы протоколов через приложения, как в системе iOS, например, Cloudflare или AdGuard. Кратко опишем в чем суть технологий и зачем они нужны.
Сначала немного о сути проблемы. Если обратиться к отчету 2019 Global DNS Threat Report компании IDC, то можно видеть, что DNS является одним из популярных векторов кибератак. 82% компаний подвергались DNS атакам разного рода, среди которых наиболее часты: DNS фишинг и спуффинг, DNS туннелирование. И часто такие атаки приводят к выводу из строя приложений и операционных систем, компрометации конфиденциальной информации. DNS протокол сам по себе не предоставляет механизмов обеспечения безопасности, он разрабатывался у истоков формирования сети интернет, и основными его задачами были прозрачность исполнения и легкое масштабирование. Над проработкой безопасности DNS начали задумываться уже в 90-х годах и в 1997 был выпущен RFC 2065 о DNSSEC – реализация функций проверки данных DNS. Технология DNSSEC имеет ряд слабых мест, в частности, отсутствие обеспечений конфиденциальности запросов и сложности в масштабировании, поэтому не получила широкого распространения.
Появилась идея более сильного решения – инкапсуляция DNS запросов в VPN. Сейчас существует два варианта реализации: DNS over TLS (DOT) и более молодой DNS over HTTPS (DOH). DOH по сути является инкапсуляцией DNS over HTTP over TLS. Основное отличие протоколов это:
- Сетевые порты — DOH использует стандартный 443 порт, и поэтому практически не детектируем. DOT использует свой порт.
- Уровень выполнения в системе – DOH использует реализацию HTTP, по сути это метод HTTP Post/dns-query. DOT может реализоваться на уровне системы, поэтому упрощает обращение к нему нативных приложений.
Оба протокола обеспечивают конфиденциальность и целостность информации в DNS запросах. Для реализации требуется готовая инфраструктура DNS с поддержкой DOT и DOH. Уже существует ряд серверов, отвечающих на такого рода запросы, например, name-серверы Google или Cloudflare. Но пока это “узкое горлышко” в технологии, которое может негативно сказаться на опыте ее использования. Развитие происходит планомерно и подкрепляется давлением со стороны растущего веса конфиденциальности информации и одновременного тренда блокирования популярных ресурсов. Производители ОС и ПО активно интегрируют DOT и DOH в свои решения.
Предлагаем Вам посмотреть комикс на английском языке о DNS over HTTPS и технологиях DOH, нарисованный компанией Mozilla.
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 являются предвестниками новой парадигмы в области практической информационной безопасности, когда механизмы доверия выстраиваются не на уровне сетевых узлов, даже не на уровне операционной системы, а на уровне конкретных приложений. Одним из существенных факторов такого перехода, несомненно, является реакция на глобальное движение в сторону сегментации Сети. Конечно, расщепление некогда плоского Интернета на логические области уровня приложений, каждый из которых контролируется некоторой корпорацией, -тоже сегментация. Но этот, вполне конкретный, процесс является попыткой использовать владение богатейшим технологическим инструментарием для того, чтобы упредить наметившиеся тенденции обособления сетей. Эта попытка имеет большие шансы стать успешной.