Новые технологии делают бесполезными системы блокировок «нежелательных» интернет-сайтов

Популярность протокола DNS-over-HTTPS для передачи зашифрованных запросов DNS набирает обороты. Google планирует представить технологию уже в следующей сборке браузера Chrome со значительно большим числом CDN-партнеров.

Разработчики проекта Chromium из компании Google объявили о планах экспериментальной обкатки нового протокола шифрования «DNS поверх HTTPS» (DNS-over-HTTPS, DoH) в следующей сборке браузера Chrome под номером 78, стабильный релиз которого ожидается 22 октября 2019 г.

Протокол DNS-over-HTTPS обеспечивает обработку запросов на получение информации о домене сайта (DNS) через криптографически защищенный протокол HTTPS. Первой о включении DoH по умолчанию в одной из следующих сборок своего браузера Firefox на днях объявила Mozilla Corporation.

В отличие от осторожничающей Mozilla, планирующей постепенный ввод поддержки DNS-over-HTTPS для части пользователей в США с единственным CDN-партнером (Content Delivery Network – сеть доставки контента) Cloudflare, эксперимент Google изначально носит более масштабный характер.

Так, непосредственно на старте проекта разработчики браузера Chrome объявили о поддержке со стороны сразу шести CDN-провайдеров, уже внедривших DNS-over-HTTPS на своей стороне. В анонсе проекта Chromium также упоминается, что проект будет доступен «для небольшой части пользователей Chrome», однако не упоминаются какие-либо географические ограничения эксперимента, что потенциально дает возможность участия в нем жителям разных стран.

Ключевая идея эксперимента с внедрением протокола «DNS поверх HTTPS», по словам разработчиков Google, заключается в увеличении безопасности и конфиденциальности пользователей в Сети. Так, например, при подключении по общедоступной сети Wi-Fi протокол DoH не позволяет другим пользователям Wi-Fi определять посещаемые другими пользователями веб-сайты, а также предотвращает взлом ПК с помощью DNS-спуфинга («отравление кэша DNS») или фарминга (скрытного перенаправления на ложный IP-адрес).

В своей публикации в блоге Google Кенджи Бахе (Kenji Baheux), менеджер по продуктам Chrome, назвал это движением в сторону «повышения безопасности использования интернета».

На практике одновременное внедрение поддержки протокола DNS-over-HTTPS в браузере и на стороне а означает дальнейшую бесполезность систем фильтрации трафика для блокировки «нежелательных» интернет-сайтов — по крайней мере, для тех сайтов, которые размещают хостинг у таких CDN-провайдеров. (а ведь Россия поспешила потратить миллионы рублей на подобные, ставшие бесполезными системы бокировок - ЭР)

По данным разработчиков Google, на старте эксперимента с внедрением протокола «DNS поверх HTTPS» в следующую версию браузера Chrome примут участие, как минимум, шесть CDN-провайдеров, внедривших на своей стороне поддержку DoH в свою службу DNS – это Cleanbrowsing, Cloudflare, DNS.SB, OpenDNS, Quad9 и, собственно, сама Google. К моменту запуска проекта список партнеров потенциально может быть расширен, отмечают авторы проекта.

Служба обработки DNS-запросов при этом остается той же – изменится только протокол обращения, который теперь будет защищен шифрованием. В результате, заверяют в Google, все элементы управления контентом DNS-провайдера, в том числе, активированные системы родительского контроля, останутся активными.

На стадии эксперимента предполагается, что при обращении к сайту браузер Chrome 78 будет проверять, входит ли DNS-провайдер пользователя в список DoH-совместимых CDN-партнеров, и затем обновит поддержку DoH от этого партнера. В случае, если DNS-провайдера не найден в списке поддерживаемых, Chrome продолжит работать в нынешнем режиме – без активации DoH.

Таким образом, в перспективе любые попытки фильтровать трафик и блокировать сайты по доменному имени будут успешны лишь для тех интернет-ресурсов, которые размещают свои ресурсы у хостинг-провайдеров с «устаревшими» платформами – то есть, без поддержки «DNS поверх HTTPS».

В рамках эксперимента разработчики Google планируют, главным образом, проверить качество реализации поддержки DoH в браузере Chrome, а также оценить влияние этого нововведения на скорость обмена данными.

Эксперимент будет проводиться на всех платформах, поддерживающих Chrome, кроме Linux и iOS. Так, пользователям мобильных устройств под управлением ОС Android 9 и выше для поддержки DoH в Chrome можно указать поставщика DNS-over-TLS в настройках частного DNS. В случае невозможности поддержки DoH настройки просто «откатятся» к стандартным настройкам частного DNS.

В случае сбоя работы протокола DoH или слишком медленного соединения при его использовании, настройки браузера Chrome также вернутся к стандартной настройке служб DNS-провайдера. От участия в эксперименте при использовании Chrome версии 78 также можно отказаться, отключив флажок в настройках браузера: chrome://flags/#dns-over-https.

Разработчики проекта Chromium также отметили, что из эксперимента с обкаткой DoH исключено множество вариантов развертывания браузера, включая версии корпоративных и образовательных клиентов. В частности, о специфических политиках поддержки DoH для компаний будет рассказано позже, в корпоративном блоге Chrome Enterprise.

Как работает DNS-over-HTTPS

Для блокировки сайтов провайдерам или регуляторам требуется знать доменное имя (URL), получаемое через DNS-запрос, и IP-адрес блокируемого ресурса. В случае, если DNS-запрос скрыт шифрованием – например, с помощью протокола DNS-over-HTTPS, провайдер не сможет блокировать конкретный ресурс из-за скрытого от него URL.

Другой вид блокировки – по IP-адресу – регулярно практикуется провайдерами и регуляторами. В частности, Роскомнадзор блокировал и затем был вынужден разблокировать миллионы IP-адресов облачной площадки Amazon Web Services в рамках борьбы с мессенджером Telegram.

В случае, если заблокированный ресурс предоставит один IP-адрес для открытого DNS-запроса и другой для DNS-запроса с шифрованием по протоколу DNS-over-HTTPS, блокировки также станут бессильны. Техническими партнерами для реализации такой возможности выступают современные CDN-провайдеры.

Технически незашифрованный URL может быть также перехвачен через поле запроса SNI (Server Name Indication) – специальное расширение протокола TLS, в котором есть возможность сообщить имя хоста в процессе «рукопожатия» для открытия криптографически защищенной SSL-сессии.

Для этих целей разработан стандарт зашифрованной передачи имени хоста – Encrypted SNI (ESNI), где клиентская система получает публичный ключ сервера из DNS и производит шифрование всех данных еще до начала TLS-сессии. Ряд CDN-провайдеров, экспериментирующих с внедрением DNS-over-HTTPS, также поддерживают технологию Encrypted SNI.