dxdt.ru: занимательный интернет-журнал

Microsoft сообщает, что планирует внедрить поддержку DNS-over-HTTPS и DNS-over-TLS в ОС Windows. На ресурсе D-Russia.ru – мой комментарий по этой теме.

Много сообщений о том, что Интернету 29 октября 2019 года исполнилось 50 лет. В качестве точки отсчёта приводят факт обмена сообщениями между двумя компьютерами, которые находились на большом удалении (600 км) – этот обмен, согласно записям, произвели 29 октября 1969 года (Charley Kline, UCLA и SRI). Это событие, впрочем, моментом возникновения Интернета – не является.

Дело в том, что Интернет – это стек протоколов TCP/IP. Именно внедрение этих протоколов и сделало уже существовавший набор каналов связи между узлами-компьютерами – Интернетом. TCP/IP внедрили в 1983 году. От этого момента, действительно, следует отсчитывать годы истории Интернета. Раньше – это были другие сети (в частности, одна из версий ARPANET).

Факт передачи сообщений между некоторыми электронными устройствами, без всяких сомнений, имеет фундаментальное значение. Однако, если строить хронологию именно от такого события, то первенство следует отдать электросвязи, а именно – телеграфу (электрическому). По той простой причине, что телеграфные аппараты, к 1969 году, уже много десятков лет обменивались сообщениями, в автоматическом режиме, через специальную сеть связи.

Конечно, в случае с историческим экспериментом, устроенном при помощи компьютеров, есть целый ряд особенностей: применялись другие протоколы, целью являлось создание некоторой общей “вычислительной среды” (то есть, перенос на большое расстояние возможности доступа к вычислительным ресурсам удалённой системы, выполненный масштабируемым способом). Но именно эти особенности хорошо подтверждают тот факт, что Интернет появился позже: раз мы отличаем телеграф от ARPANET по протоколам, то давайте вспомним, что в Интернете используется TCP/IP, которого, как раз, ещё не было в исходном эксперименте 1969 года.

Очень много сообщений про DNS-over-HTTPS в Firefox, про то, что внедрение этого протокола, якобы, “позволяет обходить любые блокировки и DPI”. Между тем, DNS-over-HTTPS (DoH) в Firefox – это способ сокрытия DNS-запросов и DNS-ответов от третьей стороны, причём скрываются только запросы от браузера до рекурсивного резолвера (подразумевается, что до резолвера Cloudflare). Заметьте, что использование DoH не скрывает рекурсивные запросы, источником которых является браузер Firefox. Например, если некоторую уникальную DNS-метку встроить в веб-страницу, то на авторитативном сервере будет видно, откуда пришёл рекурсивный запрос, соответствующий конкретной сессии конкретного браузера. По IP-адресу источника запроса (рекурсивного резолвера), по некоторым другим признакам, можно определить, используется ли клиентом штатный DNS от провайдера доступа, или это та или иная реализация DoH. В качестве источника DNS-меток (такой источник принято называть “праймером”) с большим охватом может работать любой популярный веб-сервис или веб-сайт: например, какой-нибудь веб-счётчик (что-то подобное “Яндекс.Метрике”), страница популярной социальной сети и т.д.

Однако на пути от браузера до рекурсивного резолвера, действительно, запросы и ответы DNS не будут видны третьей стороне, просматривающей трафик, так как они в HTTPS защищены шифрованием. Но к “обходу блокировок” это относится весьма косвенно.

Предположим, что блокировка доступа к веб-ресурсу осуществляется провайдером на уровне DNS. Смысл подобного метода блокирования в том, чтобы браузер (или другие программы-клиенты) не мог определить подлинный IP-адрес, с которым требуется установить соединение. Как такая блокировка работает?

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

В продвинутом варианте, уже система DPI обнаруживает все DNS-запросы и DNS-ответы, вне зависимости от того, к каким DNS-серверам они отправлены и от каких получены. Фильтрующий узел вмешивается в трафик в том случае, если силами DPI обнаружены запросы, относящиеся к заблокированным именам. Вмешательство в трафик может выражаться как в подмене ответов, так и в блокировании запросов; конечно, можно заблокировать и ответы. В этом случае DoH помогает, так как DPI перестаёт видеть DNS-трафик. Однако тот же фильтрующий узел и DPI можно настроить так, что они будут блокировать трафик DoH. Блокировать придётся весь трафик, а DPI потребуется очень серьёзно доработать. При этом в Firefox по умолчанию будут встроены средства, позволяющие предотвратить автоматическое включение использования DoH. Эти средства предназначены для корпоративных сетевых сред, где фильтрация DNS нередко является обязательным требованием “политик безопасности”. Такое поведение браузера пользователь может преодолеть, если включит использование DoH вручную.

(Отмечу, в скобках, что все описанные выше методы с подменой информации DNS противоречат DNSSEC и, соответственно, будут обнаружены, если клиент поддерживает DNSSEC.)

Защита от просмотра DNS-трафика никак не влияет на блокировку доступа непосредственно по IP-адресу узла: если соединение с конкретным адресом установить не удаётся, то не важно, как этот адрес был получен – через “открытый DNS” провайдера или через “защищённый DNS-over-HTTPS”. Да, нетрудно предложить вариант, в котором IP-адреса постоянно изменяются, а “верный адрес” передаётся только при использовании сервиса DoH. Так можно устроить, если авторитативные серверы DNS соответствующей доменной зоны как-то связаны с провайдером сервиса DoH. Однако при этом активная система блокирования может узнавать “верные адреса”, просто используя свой экземпляр браузера Firefox. Конечно, всегда остаётся экстенсивный вариант развития данной схемы, при котором, с одной стороны, сотни тысяч IP-адресов случайно распределяются по DNS-ответам, а с другой стороны – какие-то, – возможно те же, – сотни тысяч и миллионы адресов попадают под превентивную блокировку. При этом DoH здесь помогает только тем сервисам, у которых очень много IP-адресов.

Нередко можно услышать, что данный метод, применительно к проблеме блокирования доступа, хорош тем, что его трафик, по внешним признакам, не отличается от “обычного HTTPS” (то есть, от HTTPS для веб-сайта). Мало кто готов блокировать весь HTTPS-трафик. Конечно, приложив достаточно вычислительных мощностей, попытаться отличить трафик DoH от работы с веб-сайтами – можно: есть IP-адреса, есть характеристики отправляемых и принимаемых пакетов, продвинутая система блокирования умеет делать проверку сервисов (connection probe) и так далее. Другое дело, что ресурсов для блокирования потребуется действительно много и будут ложные срабатывания. Более того, в качестве следующего шага по защите возможно заворачивание DNS-трафика в “самый настоящий” HTTPS-сеанс работы с обычным веб-сайтом: DNS-запросы могут передаваться браузером в качестве нагрузки, в специальных HTTP-заголовках; и в таких же HTTP-заголовках сервер пришлёт ответы.

В целом, сверхидея DNS-over-HTTPS хорошо укладывается в самую современную концепцию в области информационной безопасности. В этой концепции “доверенными” являются только приложения – клиентское и серверное. То есть, даже операционная система не относится к доверенным. Криптография позволяет двум приложениям надёжно идентифицировать (и аутентифицировать) друг друга: браузер Firefox, используя принесённые с собой TLS-сертификаты, идентифицирует и аутентифицирует серверное приложение, которое исполняется на узлах Cloudflare и реализует сервис рекурсивного опроса доменных имён. Для схемы не важно, каким образом, по каким транзитным сетям, приложения устанавливают между собой соединение. Да, тут есть масса оговорок – про аппаратуру, которая исполняет команды; про ядро ОС, имеющее полный доступ к памяти приложений; и так далее. Но, тем не менее, логическая концепция именно такая. Развитие этой идеи в ближайшем будущем приведёт к тому, что появятся “различные интернеты”, работающие внутри того или иного приложения. Но это другая история.

Вернёмся к DoH в браузере Firefox. Данный инструмент, сам по себе, не является универсальным средством, “позволяющим обходить все блокировки”, но он защищает от утечки информации о DNS-запросах/DNS-ответах на “последней миле”: то есть, на пути от резолвера до браузера. При этом браузер замыкает на стороне пользователя некоторый особый контур, в который теперь входит и защищённая доставка контента (TLS на веб-сайтах), и собственный сервис доменных имён. “Интернет – это то, что показывается в браузере”.

Некоторое время назад в СМИ обсуждалось введение в Казахстане “обязательного TLS-сертификата”, который требовалось установить на клиентские устройства, что позволяло выполнять прозрачный перехват TLS-трафика. Эта история уже не новая: такая же схема обсуждалась в Казнете несколько лет назад.

Внедрение этого, весьма спорного, метода анализа защищённого трафика в 2019 году вызвало бурные возражения. В итоге: период, когда сертификат активно использовался (несколько недель в июле-августе 2019 года), сейчас обозначили как “тестирование применения сертификата безопасности”; сам сертификат теперь, после завершения “тестирования”, официально рекомендовано удалить с устройств (если пользователь его установил), для чего уже опубликованы инструкции.

На сайте Statdom.ru (это проект Технического Центра Интернет) опубликована статистика по проникновению технологии ESNI в российских национальных доменных зонах. Напомню, что ESNI позволяет скрыть имя сервера, с которым соединяется клиент, при установлении TLS-соединения. Сейчас ESNI поддерживается браузером Firefox. На стороне сервера с поддержкой пока не очень хорошо, но Cloudflare её уже реализовали, поэтому заметное количество TLS-узлов ESNI уже поддерживают, а в Рунете уже свыше 140 тыс. доменов с ESNI.

Немного об одном интересном техническом аспекте. ESNI подразумевает размещение ключей в DNS, поэтому для сбора статистики требуется анализировать ресурсные записи. Соответствующий черновик RFC (draft-02) предписывает хранение данных ESNI в TXT-записи (Base64) для имени специального вида: _esni.name.tld (то есть, к имени узла, с которым устанавливается соединение, добавляется префикс _esni – подробнее описано в отдельной записке). Таким образом, для получения статистических данных выполняется сбор TXT-записей. При этом во многих случаях авторитативные серверы DNS так настроены, что отвечают на запрос TXT-записи для любого имени внутри зоны. Но, естественно, в ответ приходит не ESNI. Спецификация предусматривает для ESNI контрольную сумму, проверка значения этой суммы как раз и позволяет отличить настоящие ESNI от “каких-то” TXT-записей. Именно поэтому в отчёте на Statdom.ru присутствует колонка, в которой дано количество зон с некорректными TXT-записями для ESNI-имени.

Описанная только что проблема с размещением ESNI в DNS при помощи TXT-записей – известна. Поэтому более свежие версии черновика RFC предусматривают использование нового типа DNS-записи, специально выделенного для ESNI. Соответственно, после того, как такой тип выделят (и, скорее всего, появится RFC), ключи ESNI будут распространяться под именем без префикса _esni.

Особенно интересно, что в составе ESNI-записи смогут передаваться и адреса (IPv4, IPv6) узлов, с которыми клиенту следует соединяться, используя ключи ESNI. То есть, ESNI, фактически, замещает A- и AAAA-записи. (Конечно, всё это только после того, как появится новый тип и его поддержка DNS-серверами.)

На сайте ТЦИ также опубликована моя статья, популярно рассказывающая про технологию ESNI.

Под “спутниковыми интернетами” здесь подразумевается предоставление глобального “широкополосного” доступа к Интернету спутниковой группировкой. Таких систем предлагается несколько, а сами аппараты уже начали запускать: например, Starlink и OneWeb. Я уже писал, что подобная спутниковая система является отличной платформой для создания универсального орбитального радара, предназначенного для наблюдения за поверхностью Земли. В этот раз речь о другом: насколько легко будет обнаруживать наземные станции, используемые для доступа к данному спутниковому каналу связи?

Понятно, что наземный терминал должен излучать сигнал, который непосредственно может принимать спутник (варианты с доставкой одного “плеча” по традиционным наземным каналам – конечно, возможны, но это не то, чего ожидаешь от беспроводной “технологии будущего”). А раз терминал излучает, то его работу можно обнаружить при помощи пассивного приёмника. (Здесь необходима оговорка про направленные антенны: у антенн существуют боковые лепестки диаграммы направленности, они есть даже у узконаправленных антенн, а вопрос только в коэффициенте усиления утекающего сигнала; да, в теории, можно минимизировать боковые утечки, но такая антенна вряд ли подойдёт для спутникового терминала.)

Высокочастотные сигналы (то есть, сигналы с малой длиной волны), используемые для создания цифрового канала связи, обычно имеют и хорошо узнаваемую сигнатуру, и встроенные метки времени (требуются для синхронизации). Это означает, что несколько приёмников, имеющих точное общее время и находящихся на некотором расстоянии, смогут вычислять положение спутниковых терминалов в режиме реального времени с высокой точностью и тут же “наносить точки на карту”.

Разместить приёмники, предназначенные для мониторинга радиоэфира, можно на вышках сотовой связи – они давно служат платформой для решения сходных задач: здесь есть куда поставить антенны, есть источники времени, есть каналы передачи данных и гарантированное питание. Соответствующее оборудование могут устанавливать те же “интеграторы”, которые разворачивают системы сотовой связи. Покрытие вышками в российских городах хорошее.

В теории, сигнал, используемый для организации спутникового канала, может быть замаскирован (например, если у наземного терминала и спутниковой группировки есть общие секретные ключи, то возможна реализация довольно “скрытного” кодирования). Однако, во-первых, резко упадёт пропускная способность, так что ни о каком “широкополосном” доступе речи уже идти не может; во-вторых – некоторый сигнал всё равно остаётся и его можно обнаружить, используя в качестве опорных сигналы специально закупленных терминалов и сигналы спутников. А главное, что о маскировке сигнала терминалов речи, конечно, не идет. Так что с обнаружением и геолокацией источников – проблем не возникнет.

(Записка с перечнем поддерживаемых элементов протокола TLS 1.3. Чтобы не потерялось.)

Тестовый сервер TLS 1.3 на tls13.1d.pw:

1. Версия протокола: 1.3 (0x0304), Draft-28 (совпадает с 1.3, кроме номера версии) и Draft-23 (в этой версии есть небольшие отличия в алгоритмах от 1.3, версия до сих пор встречается на практике). Вообще, draft-версии соответствуют черновикам RFC, протокол реализовывался (в статусе экспериментального) параллельно с разработкой RFC. Например, Draft-23 был очень распространён: его поддерживали и Firefox, и Chrome. Когда я запускал тестовый сервер, RFC ещё не было, и именно версия Draft-23 была основной.

2. Криптосистема подписи: сейчас используется ECDSA в группе P-384; раньше был вариант в группе P-256 (это названия кривых), можно сделать оба варианта (попеременно выбирать для каждого запроса), но тогда нужна обработка второго сертификата – возможно, добавлю. А вот поддержку RSA пока решил не добавлять.

3. Поддержка DH (при согласовании общего секрета в рамках установления соединения): P-256, P-384, x25519, а также “классический” FFDH с разрядностью 3072 бита (поддерживается, например, Firefox).

4. Шифры: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20Poly1305. Нет CCM-режимов.

5. Поддержка HelloRetryRequest: сервер, с некоторой вероятностью, отвечает на ClientHello сообщением пересогласования параметров – HelloRetryRequest (HRR), запрашивая другую группу из поддерживаемых клиентом; это происходит только в том случае, если набор групп, заявленный клиентом, позволяет. Это довольно богатое для целей исследования реализаций TLS направление, потому что здесь, в том или ином виде, требуется сохранение состояния соединения. Пример: предположим, что клиент заявляет для DH поддержку x25519, P-256 и FFDHE-3072, но ключ передаёт только для x25519 (это обычная ситуация в TLS 1.3); в таком случае сервер может ответить HelloRetryRequest, запросив либо P-256, либо FFDHE-3072.

6. Поддержка TLS cookie: при ответе с HelloRetryRequest – сервер передаёт клиенту TLS cookie. Это специальное расширение ClientHello/HelloRetryRequest, в котором передаётся некоторое значение – клиент должен вернуть это же значение в новом запросе ClientHello; у TLS cookie две основных роли: 1) “выгрузить” клиенту представление состояния начинающейся сессии, чтобы сервер не хранил дополнительные записи на своей стороне; 2) проверить, что клиент действительно активен и отвечает на запросы по адресу, с которого получено сообщение ClientHello. (Тестовый сервер совпадение значений TLS cookie не проверяет.)

7. Поддержка ESNI: поддерживается два варианта криптосистем DH – P-384, x25519 (в ESNI используется протокол Диффи-Хеллмана со статическими ключами, которые публикуются в DNS); шифр для ESNI – один: AES-128-GCM.

Некоторое время назад тестовый сервер TLS 1.3, который я реализовал и, в меру сил, поддерживаю по адресу tls13.1d.pw, продемонстрировал свою практическую полезность. А я забыл об этом написать на dxdt.ru – соответственно, пишу сейчас.

Тестовый сервер поддерживает сочетание HelloRetryRequest (HRR) и ESNI (зашифрованное поле SNI). То есть, сервер иногда отправляет клиенту запрос на пересогласование параметров и при этом обрабатывает ESNI. HRR+ESNI – весьма редкое сочетание, на обычном сервере скорее не встречается (но может быть имитировано в рамках активной атаки), это и позволило мне обнаружить в NSS (библиотека, используемая браузером Firefox) ошибку, которая до этого успешно прошла через релиз-тесты.

Ошибка состояла в следующем: использование ESNI должно скрывать имя сервера, но в NSS соединение с HRR+ESNI обрабатывалось некорректно, соответственно, во втором ClientHello, в ответ на запрос HRR, имя сервера передавалось в открытом виде (в обычном расширении SNI). В итоге – утекало имя сервера, а на tls13.1d.pw в некоторых случаях не удавалось отобразить сведения про ESNI для пользователей Firefox (причина в том, что во втором ClientHello, из которого только и имеет смысл брать сведения о соединении, ESNI просто не было). Об ошибке я сообщил в Mozilla, ошибка (Bug 1517714) исправлена в релизе NSS_3.43, вышедшем в марте. Сейчас исправленный релиз уже разошёлся по всем основным сборкам браузера Firefox.

Существенная часть информации о TLS-соединении доступна системам инспекции трафика (DPI). Чаще всего, конечно, упоминается поле SNI (Server Name Indication), в котором передаётся имя сервера. Для маскировки SNI в TLS 1.3 уже предложен дополнительный механизм Encrypted SNI.

Версии TLS ниже 1.3 подразумевают передачу серверных TLS-сертификатов в открытом виде (на начальном этапе установления соединения). В состав сертификата входят и имена сервера (может использоваться несколько), и открытый ключ сервера. Открытый ключ так же идентифицирует сервер, однако в некоторых случаях один и тот же ключ может использоваться с разными именами. Серверный сертификат является важным признаком классификации TLS-соединений, с другой стороны, сертификат имеет существенный размер и требует наличия в составе DPI-системы функций, которые могут разобрать сертификаты по полям и проанализировать – всё это заметная дополнительная вычислительная нагрузка, особенно, если соединений много.

В открытом виде (версии меньше 1.3) на начальном этапе передаются и клиентские сертификаты, которые в TLS используются для аутентификации клиента сервером. Клиентские сертификаты часто применяются в решениях VPN, соответственно, анализ клиентского сертификата в этих случаях позволяет точно распознать начало VPN-соединения.

В TLS 1.3 – сертификаты уже передаются в зашифрованном виде (и серверные, и клиентские), таким образом, переход на TLS 1.3 закрывает данную утечку информации в сторону DPI. (В принципе, передать клиентский сертификат в зашифрованном виде можно и в TLS предыдущих версий, но для этого потребуется сначала установить TLS-соединение, а потом – отправить  с сервера запрос аутентификации, что не всегда совпадает с логикой использования протокола приложением.)

Особенно мощная система DPI может вести статистику соединения: в TLS-трафике присутствует открытая последовательность TLS-записей, поэтому анализирующая поток данных система видит размеры записей, а также их типы. Здесь, опять же, существенный шаг вперёд проделан в версии TLS 1.3. А именно: реальные типы записей в TLS 1.3 скрыты – виден только “исторический” тип Application, назначаемый всем записям в фиктивном заголовке, это делает поток типов однородным, полностью убирая важный источник метаданных для классификации трафика. В более ранних версиях TLS типы записей передаются в открытом виде, так что анализатор потока может обнаружить состояние TLS-сеанса (так как протокол использует записи разных типов для передачи сигналов, сообщений об ошибках и пр.)

DPI видит длину отдельных TLS-записей. Однако TLS позволяет приложению разными способами маскировать реальную длину передаваемых данных. А в TLS 1.3 имеется специально для этой цели предназначенный механизм на уровне защищённого транспорта: длина записей может выравниваться с помощью дополнения. Это означает, что реализация в версии 1.3, минимизирующая утечки метафинформации, может превратить поток данных в последовательность TLS-записей одинакового типа и одинаковой длины – DPI будет сложно за что-то зацепиться.

Подобный статистический анализ трафика требует существенных ресурсов: DPI необходимо не только собирать отдельные пакеты в сессии, но и выделять заголовки, накапливать данные для каждой сессии.

Естественно, хорошо защищённый протокол должен свести к минимуму утечки метаинформации. Это, частично, уже сделано в TLS 1.3, однако TLS является весьма универсальным протоколом, который, к тому же, проектировался с учётом повышения его эффективности в роли транспорта для массовых соединений, а не как протокол, скрытый от DPI. Поэтому пассивные анализаторы трафика всё ещё получают из TLS-соединения дополнительную информацию об узлах и состоянии приложений (дополнительную – по сравнению, например, с информацией уровня TCP, к которой относятся адреса узлов, номера портов, порядок и размер TCP-пакетов и др.). Методы криптографии позволяют спроектировать хорошо замаскированный протокол, но каждый шаг маскировки снижает эффективность, в частности, увеличивает затраты на установление соединения (это перебор адресов, генерация дополнительных секретов и т.д.). Тем не менее, ситуация тут такова, что даже небольшой, но верно спланированный шаг маскировки – существенно затрудняет работу DPI. В ряде случаев, рост “сравнительной сложности” на стороне DPI оказывается, как минимум, экспоненциальным: представьте, что специальный протокол использует перемешивание UDP-пакетов разных потоков, отправляемых по различным адресам серверов.