Dns-over-https

# wtf cf-hls-media.sndcdn.comcf-hls-media.sndcdn.com is an alias for d1ws1c3tu8ejje.cloudfront.net.d1ws1c3tu8ejje.cloudfront.net has address 13.33.240.123 13.33.240.123 заблокирован

С в очередной раз замолчавшего радио и начался тот день, когда я допилил DNS-over-HTTPS сервер для облегчения фантомных болей от творчества Роскомнадзора.

Боли эти хорошо описаны @ValdikSS в статье В России сохраняются проблемы с доступностью сайтов, но никто их не замечает.

Думать особо не приходится, суть проблем проста и решение тоже не очень сложно: достаточно выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN. Такое издевательство над DNS позволяют как минимум Cloudflare и Amazon Cloudfront.

Например, если в условном DNS-ответе от AKAMAI пришли адреса 23.1.14.0 и 23.1.20.2, а первый из них заблокирован РКН, то в таком случае DNS-сервер может отдать клиенту только один адрес из двух, и браузер не будет тупить в попытке установить соединение с заблокированным IP. Это не обход блокировок, скорее наоборот. Но оно измеримо уменьшает боль. Я был бы рад такую конструкцию увидеть у Яндекс.DNS в Безопасном режиме, но всё же не думаю, что Яндекс готов реализовать такую в меру серую фичу.

Валить в панике из страны? Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции. Можно ещё попытаться что-то починить, да посмеяться над тем, что осталось.

Но хочу предупредить, модель такого DNS-сервера по имени kabysdoh.gulag.link запущена на виртуалке в Санкт-Петербурге, поэтому её использование из других регионов России может добавить существенную задержку к вашим DNS-запросам. При наличии архива XML-выгрузок Роскомнадзора, можно взять исходный код с GitHub и запустить Unbound в подходящей локации. Поддержку Knot Resolver я с @ValdikSS допилю в каком-нибудь обозримом будущем.

Мобильные устройства на Android поддерживают DNS-over-TLS, который доступен по адресу kabysdoh.gulag.link, а Mozilla Firefox поддерживает DNS-over-HTTPS по адресу https://kabysdoh.gulag.link/dns-query. Скриншоты примерной конфигурации можно увидеть ниже (про все возможные опции DoH в Firefox можно прочитать на wiki):

У меня на сегодня всё! Надеюсь, кому-то данная конструкция будет полезна. И помните, once you step into the waters of modifying in-flight DNS messages it seems like crocodiles all the way down.

Новые протоколы 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 можно рассматривать как еще один важный шаг к безопасному интернету.

Что еще почитать по теме:

• Что лучше x86 или ARM?

• На что пересесть после ACCEL-PPP

• DNS over HTTPS безопасность или сложность в работе

• P2P-протокол Dat как работает и кем используется

• Технологии шифрования нового поколения: как они работают