Зашифрованный DNS: DoH и DoT

Предыдущий урок описал обычный DNS-запрос как открытку: её может прочитать любой, кто держит её в руках по пути. Есть два стандарта IETF, которые кладут эту открытку в конверт: DNS over TLS (DoT, RFC 7858) и DNS over HTTPS (DoH, RFC 8484). Оба шифруют один и тот же запрос; различаются они в основном тем, как они его передают.

DNS over TLS

RFC 7858 прямо формулирует свою цель: «шифрование, обеспечиваемое TLS, устраняет возможности для подслушивания и подмены DNS-запросов на пути следования», решая проблему того, что «почти все DNS-запросы отправляются без шифрования, что делает их уязвимыми для перехвата злоумышленником». DoT использует собственный выделенный порт, 853, а не обычный порт 53. RFC объясняет почему: «эта рекомендация не использовать порт 53 для DNS over TLS призвана избежать сложностей при выборе использования или неиспользования TLS и снизить риск атак с понижением уровня защиты».

DNS over HTTPS

RFC 8484 идёт другим путём: «каждая пара запрос-ответ DNS сопоставляется с обменом по HTTP», передаваемым через тот же порт 443, который использует обычный HTTPS-трафик. RFC отмечает у этого побочное преимущество: «порт 443, используемый по умолчанию для HTTPS, и возможность смешивать трафик DoH с остальным трафиком HTTPS в одном и том же соединении могут удержать непривилегированные устройства на пути следования от вмешательства в работу DNS», поскольку выделить и заблокировать такой запрос сложнее, когда он выглядит как любой другой веб-запрос.

Что скрывает шифрование, а что всё ещё нет

Оба стандарта не дают оператору сети или Wi-Fi-подслушивающему прочитать ваши запросы при передаче. Ни один из них не скрывает их от резолвера, которому вы их отправили. RFC 8484 прямо говорит, что DoH не меняет то, что способен увидеть сам сервер: там отмечается, что «различные способы передачи DNS-запросов и ответов действительно дают данные, которые можно использовать для сопоставления запросов», и что обычные веб-механизмы, такие как IP-адрес клиента, cookie-файлы и данные сессии TLS, означают, что «DoH не привносит новых проблем по сравнению с теми, что уже связаны с HTTPS», на стороне сервера. RFC 7858 схожим образом отмечает, что DoT «не решает другие проблемы безопасности DNS» и что «даже при зашифрованных сообщениях хорошо расположенная сторона может извлечь определённые сведения из анализа времени и размера сообщений». Короче говоря: зашифрованный DNS перемещает того, кто видит ваши запросы, к оператору выбранного вами резолвера, а не устраняет видимость полностью.

Есть и второй пробел, о котором стоит знать. Само по себе шифрование DNS-запроса не скрывает, к какому сайту вы затем подключаетесь: следующее за этим рукопожатие TLS обычно передаёт имя хоста в открытом виде. Как объясняет Cloudflare, рассказывая об индикации имени сервера (SNI), «SNI включает имя хоста в сообщение Client Hello — самый первый шаг рукопожатия TLS», отправляемый ещё до установления шифрования. Расширение Encrypted SNI (ESNI), поясняет тот же источник, «дополняет расширение SNI, шифруя его часть в сообщении Client Hello», что «не позволяет тому, кто подслушивает соединение между клиентом и сервером, увидеть, какой сертификат запрашивает клиент». Поддержка сокрытия SNI по-прежнему зависит от согласия и браузера, и сайта, и пока работает не в каждом соединении.

Как это поддерживает macOS

Apple описывает настройку DNS для Mac, iPhone и iPad, которая делает именно это: она позволяет устройству «направлять DNS-запросы устройства через зашифрованный DNS-сервер с помощью DNS over HTTPS или DNS over TLS». Она поставляется в виде конфигурационного профиля, который может ограничивать зашифрованный резолвер конкретными доменами через «дополнительные домены соответствия» или применяться только в определённых сетях с помощью «правил по требованию», которые могут учитывать, например, имя сети (SSID).