Новые протоколы DNS-over-HTTPS и DNS-over-TLS стали настоящим яблоком раздора в ИТ-сообществе. Шифрование DNS-запросов внедряет во все большее число браузеров, но среди экспертов есть и те, кто критикует этот подход. Они считают, что новые протоколы не оказывают положительного влияния на степень защищенности и в лучшем случае «бесполезны».
Разберем несколько наиболее популярных аргументов по этому вопросу.
Возможность мониторинга остается
Протоколы DoH и DoT шифруют запросы к DNS-серверу и ответы на них. В теории такой подход должен надежно скрывать имена хостов, к которым обращается пользователь, от интернет-провайдера и злоумышленников. Однако на практике с этим возникает ряд нюансов.
В этом году эксперты из аналитической компании SANS Institute опубликовали исследование, посвященное анализу DNS-трафика в корпоративных сетях. Они провели серию тестов и сделали вывод, что инструменты для логирования, проксирования и криптоанализа позволяют получить точное представление о содержимом зашифрованных DNS-запросов (стр. 21).
В то же время основатель PowerDNS Берт Хуберт (Bert Hubert) говорит, что DoH шифрует данные, которые можно без особого труда получить в открытом виде из других источников. Например, интернет-провайдеры могут определить сайты, которые посещает клиент через протокол OCSP (RFC 6960). Он служит для получения статуса отзыва цифрового сертификата X.509 (описывает процедуры распределения открытых ключей). Ответы OCSP содержат серийный номер TLS-сертификата на сайте, и по нему легко определить название ресурса.
Есть уязвимые места
Специалист по информационной безопасности и один из разработчиков открытого дистрибутива Whonix отмечает, что существуют и другие способы заполучить информацию о посещаемых сайтах. Один из вариантов — анализ Server Name Indication (SNI). Это — расширение протокола TLS, и через него клиенты сами сообщают имя хоста, к которому желают подключиться.
Информация транслируется в открытом виде, и при желании её можно перехватить. Справедливости ради стоит отметить, что уже есть инструменты, позволяющие шифровать SNI — например, проект Encrypted Client Hello (ECH). Он скрывает метаданные, передающиеся во время рукопожатия, однако инструмент и его аналоги пока не получили широкого распространения.
Даже если шифровать DNS-запросы и использовать другие предосторожности, остается пусть и очевидный, но весомый момент, связанный с IP-адресом ресурса, к которому подключается клиент. По оценке специалистов регионального интернет-регистратора APNIC, его достаточно для точной идентификации более 95% сайтов. В оставшиеся 5% входят IP-адреса, связанные с несколькими ресурсами. Но и эту проблему — при желании — можно обойти.
Новые кибератаки
Еще в 2019 году специалисты по информационной безопасности из Netlab обнаружили вредонос Godlua. Программа злоупотребляет особенностями DNS-over-HTTPS для проведения DDoS-атак. С помощью протокола зловред маскирует обмен данными с управляющими серверами.
В итоге антивирусное ПО не может его обнаружить.
Эксперты опасались, что за Godlua последуют другие вредоносы, невидимые для систем пассивного антивирусного мониторинга. Так и получилось — в конце 2020 года в Huntress Labs обнаружили новый вирус. С помощью DoH он получает IP-адреса хостов, входящих в состав вредоносной инфраструктуры. Остается надеяться, что в ближайшее время появятся инструменты, которые помогут выявлять вредоносную активность в зашифрованном трафике корпоративных сетей и предупреждать администраторов о потенциальных рисках.
Что дальше
Можно сделать вывод о том, что для повышения приватности необходимо использовать комплексный набор инструментов, в том числе и VPN. Одного лишь шифрования DNS недостаточно для полного сокрытия «истории браузинга». Однако технологии DNS-over-HTTPS и DNS-over-TLS можно рассматривать как еще один важный шаг к безопасному интернету.
Что еще почитать по теме:
Angeld
плохо работает если если внутренняя сеть со своим днс
браузер пытается резолвить по шифрованному каналу, а удаленные днс локальное резолвить не могут
GritsanY
DoH и DoT технологии работают на уровне браузера, поэтому все не-веб сервисы локальные продолжают нормально работать. А для локальных веб-сервисов можно использовать другой браузер, «махровый»
Angeld
это и есть плохо работает, что нужны костыли для данного случая
Mur81
А в чём проблема? Если нужно резолвить внутренние имена, то DoH в браузере выключаете и всего делов. В большинстве случаев такая ситуация возникает в корпоративном сегменте, а там в любом случае должен быть админ, который этим рулит. И даже больше скажу - не знаю за все браузеры но Chome под Windows если понимает, что он работает на машине в домене сам выключает DoH (и вроде даже включить его даёт, но тут точно не помню). Ну а внутренний DNS уже настраиваете на общение с вышестоящим через DoH/DoT.
Angeld
в этом и проблема DoH, что единственное решение для пользователя в таких случаях отключить DoH
или то что DoH не работает проблемой не является?
Mur81
Если это происходит в корпоративной сети, то да - это не проблема. В этом случае не пользователя ума дело что как работает. Как я выше написал - если администратор сети считает, что DoH нужен, то он его поднимет на внутреннем DNS сервере к внешнему аплинку и весь внешний трафик будет шифроваться. Шифровать его внутри сети смысла особого нет. Но если надо, то опять же никто не мешает настроить DoH внутри периметра (если это поддерживается сервером конечно).
Собственно и с домашней сетью можно поступить аналогично если у пользователя есть соответствующие навыки (а если их нет, то и надобности резолвить внутренние имена тоже как правило нет).
Angeld
те DoH на уровне браузера бесполезен, но его зачем то упорно продвигают
хотя казалось бы он должен скрывать DNS запросы даже от провайдера
но без админов провайдера его использовать невозможно
«отключайте его когда нужно резолвить внутренние имена» это костыль
Mur81
Как это бесполезен? Он полезен именно тем что уже сегодня позволяет начать пользоваться DoH всем кто о нём даже не подозревает. И не дожидаясь пока реализация DoH/DoT появится в системных резолверах операционных систем и всяких бытовых роутеров.
В какой-то мере это конечно костыль. Но костыль вынужденный. Потому что реализацию вышеозначенного можно ждать годами. А в подавляющем большинстве SOHO роутеров, которые сейчас находятся в обращении, она не появится никогда.
У меня сейчас сложилось впечатление, что мы говорим про разные вещи. Вы видимо имеете в виду внутренние имена каких-то провайдерских сетей? А я говорил про внутренние имена в сетях корпоративных либо собственных (домашних). В случае внутренних провайдерских всё верно — это не будет работать. Но выход тоже есть (если очень надо). Например можно в качестве роутера поставить изделие MikroTik (вероятно в каком-нибудь OpenWrt это тоже можно). На его DNS-клиенте поднять DoH и указать домены-исключения (внутренние провайдерские домены) для которых будет использоваться другой DNS сервер (провайдерский). Во внутренней сети DoH на уровне браузера выключить, т.к. DNS-трафик уже шифруется роутером.
Сложно? Да. Но это потому что со стороны провайдеров это хреновая практика. Нужно размещать ресурсы в общем пространстве имён Интернета (доступ извне можно и не давать при этом), а не городить вот это вот. Потому что такие ресурсы отвалятся у всех кто прописал себе любой DNS отличный от провайдерского и DoH/DoT здесь вообще ни при чём.
Angeld
Там где позволяет может и полезен, но я говорю про конкретный случай для которого DoH предлагают отключить. Отключенный он бесполезен. Включать его через роутер не всегда применимо, ну и поддержка DoH в браузере в этом случае, так же не нужна. В данном случае требуется список исключений, но почему-то его не добавили. Для firefox я нашел ключ network.trr.excluded-domains, но он появился не так давно, в прошлы раз когда я пробовал DoH его не было, ну и в настройки его не добавили. Для chrome найти не удалось.
Размещать в общем пространстве имен локальные ресурсы не особо хорошо. Зачем они там нужны, если доступны только в приватной сети, и часто вообще бывают временными поддоменами. В результате вроде как декларируется что достаточно включить в браузере и пользоваться, а на деле приходится отключить.