Роскомнадзор добрался до TLS. DoH Google и Cloudflare зависает прямо на старте
В российских сетях начали блокировать защищённые DNS-сервисы Google и Cloudflare. Пользователи сразу нескольких операторов столкнулись со сбоями DNS over HTTPS и DNS over TLS, причём соединение с сервером зачастую успевает установиться, а затем зависает или принудительно обрывается уже во время запуска шифрования.
Первые подробные технические тесты 21 августа опубликовал Telegram-канал bypassblock. Авторы сообщили, что Роскомнадзор продолжает блокировать DoH, и показали результаты проверок в сети мобильного оператора.
DNS over TLS Cloudflare перестал нормально работать через адреса 1.1.1.1 и 1.0.0.1 на TCP-порту 853. Клиент устанавливал соединение, но затем получал ECONNRESET, то есть удалённая сторона или промежуточное сетевое оборудование принудительно сбрасывали TCP-сессию.
Похожая картина возникла с DNS over HTTPS Google. При подключении к dns.google, 8.8.8.8 и 8.8.4.4 через стандартный HTTPS-порт 443 TCP-соединение устанавливалось нормально. После отправки TLS ClientHello обмен останавливался, а клиент спустя несколько секунд завершал запрос по тайм-ауту, не получив ни одного байта ответа.
Дополнительные проверки показали и другой вариант сбоя. При обращении к https://dns.google/dns-query соединение могло оборваться непосредственно во время TLS-рукопожатия с ошибкой unexpected eof while reading. Авторы канала сообщили, что получили аналогичные результаты как минимум от трёх пользователей из разных мест.
Позднее похожие проблемы начали фиксировать абоненты других российских операторов. Сообщения о сбоях защищённого DNS поступали из сетей «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet. В отдельных случаях обычные незашифрованные запросы к публичным DNS продолжали проходить, тогда как DoH и DoT Google и Cloudflare переставали отвечать.
У некоторых пользователей DNS over HTTPS не работал сразу через несколько публичных резолверов. В других сетях проблемы затрагивали только определённые адреса или один из защищённых протоколов. Один из абонентов «Таттелекома» сообщил, что техническая поддержка оператора рекомендовала отключить DoH и DoT.
Характер сбоев показывает, что публичные DNS-серверы не обязательно блокируются полностью по IP-адресу. Устройство может установить TCP-соединение с 8.8.8.8 или 1.1.1.1, однако защищённая сессия перестаёт работать уже на следующем этапе. Такой механизм позволяет оставить доступным обычный DNS и одновременно мешать клиентам пользоваться его зашифрованными вариантами.
DNS over TLS распознать относительно просто. Протокол обычно использует выделенный TCP-порт 853, поэтому операторское оборудование может определить такой трафик уже по порту назначения.
С DoH задача сложнее. DNS over HTTPS передаёт DNS-запросы внутри HTTPS и использует тот же порт 443, через который работают обычные сайты. Поэтому простая блокировка порта невозможна. Для выборочного ограничения требуется отличать соединения с DNS-резолверами от остального HTTPS-трафика.
Наблюдаемое зависание после TLS ClientHello указывает именно на такой уровень фильтрации. Клиент успевает договориться об обычном TCP-соединении и начинает TLS-рукопожатие, но защищённый канал до DNS-сервера уже не создаётся.
DoH и DoT нужны для того, чтобы DNS-запросы не передавались по сети в открытом виде. При использовании классического DNS интернет-провайдер может видеть запросы к доменным именам и вмешиваться в ответы. Защищённые протоколы шифруют обмен между устройством пользователя и выбранным DNS-резолвером.
Google предоставляет публичный DNS по адресам 8.8.8.8 и 8.8.4.4, а Cloudflare использует 1.1.1.1 и 1.0.0.1. Оба сервиса давно поддерживают классический DNS вместе с DoH и DoT, поэтому пользователи могут отправлять запросы к тем же публичным резолверам через зашифрованный канал.
Подобные ограничения уже появлялись в российских сетях раньше. В начале июля пользователи нескольких крупных операторов фиксировали проблемы с TCP-соединениями к Google Public DNS. При этом обычные DNS-запросы по UDP продолжали работать, а часть альтернативных способов подключения оставалась доступной. Через некоторое время прежняя схема работы восстановилась.
Новая волна отличается тем, что пользователи одновременно сообщают о проблемах с Google и Cloudflare, а сбои появляются у абонентов нескольких операторов. Технические проверки также показывают характерную точку разрыва. Соединение доходит до начала TLS-сессии, после чего клиент получает сброс или бесконечно ждёт ответа.
Для обычного пользователя последствия могут выглядеть довольно буднично. Браузер или операционная система внезапно перестаёт использовать выбранный защищённый DNS, сайты начинают открываться с задержкой либо приложение автоматически переключается на другой способ разрешения доменных имён. Если предусмотренного резервного варианта нет, интернет может казаться частично неработающим, хотя само соединение с сетью сохраняется.
Фильтрация DoH и DoT расширяет возможности контроля DNS-трафика. Простого указания публичного сервера Google или Cloudflare становится недостаточно, если операторская сеть отдельно распознаёт и блокирует попытку установить с ним защищённое соединение.