Протоколы в туннелях и будущее Сети на примере DoH и ECH
Почти десять лет назад появились первые предложения о DNS-over-HTTPS (DoH). Тогда некоторые восприняли идею как шутку и даже выдвигали иронические варианты развития, например, DNS-over-GIF и другие занимательные версии. Однако в 2016 году поддержку DoH добавили на сервис DNS-резолвинга Google Public DNS, а несколько лет спустя DoH стал чем-то вроде стандартного инструмента для работы с DNS, как с сервисом, в веб-браузерах, после чего иронизировать на тему данной технологии стало дурным тоном.
DNS-over-HTTPS – хороший пример того, как изменение технологического ландшафта Интернета приводит к перемешиванию ранее привычных уровневых структур (типа устаревшей модели OSI из семи уровней): старые протоколы, чтобы продолжать работать в новых условиях, пробивают в изменившемся ландшафте туннели.
DoH представляет собой удобный программный интерфейс (API) к совсем другому сервису, а не к DNS как к системе – то есть это надстройка через два новых уровня абстракции. При этом в описаниях DoH нередко можно прочитать, что данная технология позволяет отказаться от сложностей DNS. Сколь бы странным это ни казалось, но спорить тут не о чем: если прикладная программа использует тот или иной сервис, предоставляющий DoH, то эта программа работает уже только с HTTPS и данные получает по этому же протоколу, в весьма удобном формате JSON – и действительно, в этом случае взаимодействие с DNS для прикладной программы исчезает. Другое дело, что из типичного системного окружения узла, подключенного к Интернету, на котором эта прикладная программа работает, DNS никуда не девается: даже для инициализации DoH-сервиса всё равно нужно непосредственно использовать классический доступ к системе доменных имён. Это несмотря на возможность настроить непосредственно сам IP-адрес (известные примеры: 8.8.8.8, 1.1.1.1). То есть классический доступ к DNS через “обычный” локальный резолвер никуда из системного окружения не исчезает.
Перенести решение задач DNS на другой фундамент, включающий и TLS, и HTTP, предлагается дополнительно. Конечно, базовый протокол DNS имеет свои особенности и большое количество “крайних случаев”, но сложность сочетания TLS с HTTP на порядок выше. Можно предположить, что в случае браузера поддержка и интенсивное использование TLS и HTTPS так или иначе необходимы, поэтому перенос на эту базу ещё и API доступа к DNS (то есть реализация DoH) ничего не меняет. Но, во-первых, схема тут работает в обе стороны: перенос ещё одной базовой технологии в уже имеющийся стек означает, что уязвимости и риски этого стека начали работать и для вновь поступившей технологии – в данном случае, возможные проблемы с TLS повлияют и на доступ к DNS. Во-вторых, как говорилось ранее, DNS никуда не девается из системного окружения.
Тогда почему же DoH? Базовая причина в том, что самая современная модель управления доверием в задачах информационной безопасности предполагает доверие именно между приложениями, а DoH как раз и позволяет изолировать доступ к важнейшему сервису от системного окружения, в котором конкретное приложение исполняется. Приложение “веб-браузер” с настроенным сервисом DoH создаёт туннель прямо из своего контекста до приложения “поиск в DNS” на удалённом DNS-сервисе. В рамках штатной работы приложения туннель закрыт не только для других приложений, но даже и для ядра ОС (естественно, с оговорками о том, что на уровне ядра ОС получить доступ к данным приложения внутри TLS труда не составляет). Несомненно, использовать DoH можно и для доступа к “локальному” резолверу провайдера, но это не отменяет необходимости поддерживать и “классический” вариант доступа к провайдерскому резолверу, потому что со стороны клиента DoH есть только в избранных приложениях. То есть туннели DoH здесь прямо влияют на сетевую реальность, усложняя её.
Классический вариант доступа к DNS предполагает использование протокола UDP в качестве сетевого транспорта и запросы/ответы в пакетах DNS-формата. DoH же переводит логику доставки на два уровня выше, заменяя UDP на TCP и добавляя TLS, а поверх него – HTTP, при этом запросы/ответы упаковываются в новые структуры (JSON), которых не было в DNS, а для установления TCP-соединения всё равно может потребоваться доступ к DNS.
В “классическом” Интернете сетевому инженеру нужно было бы настроить DNS-сервер (резолвер) с доступом для конечных клиентов и проверить, что DNS-пакеты успешно доставляются в обе стороны. При этом в более продвинутых вариантах в резолвере могут быть настроены разные зоны и применяться различные методы обработки запросов и имён для отдельных клиентов. Предположим, что теперь нужно перейти к использованию DoH. Дополнительно потребуется настроить TLS/HTTPS. И даже если сервер резолвинга с DoH “локальный” и для него используется программное обеспечение резолвера, в котором DoH доступен из коробки, придется настроить пропуск дополнительного типа трафика (TLS) к DNS-серверу.
Если же клиентом подключается внешний DNS-сервис с DoH, например, Cloudflare или Google, то на стороне провайдера доступа полностью утрачивается возможность локальных настроек зон и правил обработки имён. Для кого-то из пользователей это хорошо, а для кого-то – не очень: так, когда что-то не работает, не слишком продвинутые пользователи внешних сервисов DNS могут стать проблемой для службы поддержки, которой приходится догадываться, что на самом деле имеет в виду пользователь. При этом продвинутые пользователи могут получить защищённый канал до резолвера. Но в любом случае на примере DoH видно, что сдвиг парадигмы в сторону “доверия между приложениями” на сетевом уровне проявляется в виде “спагеттизации” протоколов: то, что раньше успешно ходило на своём “плоском” уровне через UDP, вдруг обрело дополнительное измерение и выписывает кривые между плоскостями. И хоть в DoH есть туннель, но это ещё не VPN.
Раньше считалось, что протоколы и сервисы работают на своих уровнях. Например, до начала HTTP-сессии сначала задействовалась DNS через UDP, а дальше, после обнаружения нужного IP-адреса и установления TCP-соединения, HTTP-клиент мог отправить команду на HTTP-сервер. Современное направление развития протоколов таково, что логические концепции размазываются и самокопируются между уровнями и туннелями: HTTP/2 затягивает в себя концепции из слоя TCP (например, разделение обмена данными на асинхронные потоки, которые, тем не менее, организованы внутри одного соединения, повторную передачу сообщений и т.д.), при этом TCP либо никуда не исчезает, либо заменяется на UDP (см. QUIC – Quick UDP Internet Connections, транспортный протокол, изначально разработанный Google и стандартизованный в IETF), но с ещё более широкими надстройками, логически копирующими аспекты TCP по управлению сессией. С одной стороны, это даёт заметные преимущества, но с другой стороны, приносит новые, неожиданные направления атак, основанных именно на переносе логических конструкций между уровнями. На надстройки накладывается практика блокирования доступа, которая едва ли уже не стала всеобъемлющей. Современное состояние этой практики тоже включает несколько логических слоёв: блокирование по “географической привязке адреса”, блокирование на стороне веб-сервиса, блокирование на уровне “классической” DNS, блокирование на стороне провайдера доступа, на стороне “облачного” провайдера, на промежуточных узлах (в обе стороны) – список не полный. Всё это сдвигает парадигму: поток сообщений HTTP/2 уже не получается ограничивать на уровне простого файрвола по количеству запросов с одного IP-адреса по номеру порта на сервере.
Типичный сценарий подключения пользователя к веб-сервису состоит (в сетевом смысле) из работы некоторого DNS-резолвера у провайдера доступа и работы NAT этого же провайдера. Однако в реальности ситуация часто оказывается гораздо сложнее: у конечного пользователя теперь настроен VPN, иногда – более одного VPN, каждый из этих VPN выполняет трансляцию адресов (получаем несколько NAT), сервис DNS частично завёрнут в VPN, частично работает через провайдера, а частично – через тот или иной внешний DNS-сервис (см. про DoH выше). Уже достаточно новых измерений для построения непростых сечений многомерных объектов. Однако есть и ещё один важный аспект, набирающий популярность: мы говорим о сервисах скрытого туннелирования.
Хорошим примером такой технологии является ECH (Encrypted Client Hello). Это способ дополнения TLS, позволяющий через тот или иной узел-посредник подключиться к скрытому сервису по TLS, не раскрывая ни имени, ни адреса этого сервиса для стороны, прослушивающей канал.
По сути, ECH с сопутствующими DNS-записями предоставляет универсальный интерфейс для туннелирования. При этом в DNS публикуются открытые ключи и конфигурация доступа. Размещение данных в DNS тут же диктует использование, как минимум, DNSSEC, но скорее DoH (или DNS-over-TLS, DoT), так как сокрытие запросов, связанных с получением конфигурации, увеличивает степень защиты от утечки информации о соединении.
ECH вместе с DoH прекрасно иллюстрируют концептуальные изменения в использовании Интернета и показывают направление расширения технологического базиса. Конечно, подобные схемы применялись и раньше, но это были весьма и весьма специализированные решения для обхода сетевых блокировок с развитым DPI – мало кто их когда-то применял и даже о них слышал (речь про варианты ShadowSocks, модификации XTLS и др.). ECH же – это полноценное развитие TLS со своими RFC, это технология, уже поддерживаемая крупными провайдерами как сервисов доставки контента (Cloudflare [2]), так и клиентского ПО (Mozilla Firefox [4], Google Chrome [3]).
Схема работы ECH следующая [6]. Обычное TLS-соединение начинается с отправки клиентом специального “сообщения-приветствия” – ClientHello. Исторически сложилось, что вокруг этого сообщения и строится ECH. Дело в том, что сообщение ClientHello не только определяет часть параметров соединения, но также обычно содержит в открытом виде имя TLS-узла, к которому собирается подключаться клиент – поле с именем узла называется SNI (Server Name Indication), и промежуточные узлы могут его прочитать. Такая конфигурация тоже сложилась исторически из практики веб-хостинга: указание имени SNI, в частности, требуется для того, чтобы можно было на узле с одним IP-адресом размещать разные виртуальные TLS-узлы. Именно из попыток скрыть имя SNI и выросла технология ECH, а возможность работы разных сервисов на узле с одним IP-адресом тут получает дополнительное развитие: IP-адрес переносится на уровень, совсем не связанный с сервисом, к которому подключается клиент. На начальных этапах проектирования ECH, когда прообраз ещё назывался ESNI, предлагалось относительно простым и прямолинейным способом скрывать только имя, итоговый же результат превратился в интересную, развитую технологию скрытого туннелирования.
В рамках ECH в состав начального сообщения ClientHello верхнего уровня встраивается зашифрованное внутреннее сообщение ClientHello, которое адресовано скрытому проксирующему узлу. Получается, что входной узел организует туннель до скрытого сервиса, который уже обрабатывает внутреннее ClientHello и устанавливает скрытое TLS-соединение с клиентом. Процесс установления соединения полностью соответствует схеме с условным названием TLS-over-TLS. Однако чтобы избежать “двойного” шифрования, последующий обмен данными уже производится между клиентом и скрытым сервисом – входной узел просто копирует данные: то есть клиент обменивается данными через туннель непосредственно со скрытым сервисом.
Таким образом, промежуточный узел, анализирующий трафик, видит только факт установления TLS-соединения (по сообщениям верхнего уровня), которое содержит параметры для, возможно, доступа к скрытому сервису – но этим фактом всё и ограничивается. При этом ECH уже не привязана конкретно к вебу и, например, HTTP. Скрытое TLS-подключение, установленное с использованием ECH, можно использовать для организации полноценного VPN-соединения на более низких транспортных уровнях. Пользователи получили защищённый метод доступа к облачным провайдерам, а с точки зрения сети добавилось несколько туннелей с разными протоколами: по TCP работает TLS-туннель, внутри которого создаётся ещё один TLS-туннель, внутри которого запускается трансляция HTTP-соединения через HTTP-команду Connect.
Массовое внедрение подобных технологий туннелирования, которые не только достаточно сложны сами по себе, но и оптимизируют соединения уже с точки зрения снижения различимости трафика разных типов, приводит к “наложению путей” доставки этого трафика, если процесс рассматривать с точки зрения базовой структуры IP и BGP. Привычный метод описания предполагает, что клиент подключается через несколько промежуточных узлов-маршрутизаторов (“ближайших” к нему в сетевом смысле) к оконечным узлам, обеспечивающим работу сервисов, будь то DNS или веб. Однако в реальности при использовании ECH с “универсальным облачным” провайдером, а тем более при использовании VPN, клиентское подключение проходит через те же ближайшие к клиенту узлы-маршрутизаторы, но уже в составе пути к входным узлам в VPN. И лишь дальше, через выходную точку VPN, через совсем другие сетевые пути, клиент подключается к оконечным узлам сервисов.
Для привычных способов использования VPN характерно разделение узлов по IP-сетям: одни сети добавляем в маршруты “через VPN”, другие сети – оставляем “без VPN”. Но распространение скрытого доступа, подобного ECH, и внедрение DoH вносят новое измерение: направления начинают разделяться по протоколам. Использование разных маршрутов в VPN означает, что к части узлов одного и того же сервиса пользователь-клиент подключается через один набор промежуточных узлов, а к другой части узлов этого же сервиса тот же пользователь-клиент подключается через совсем другой набор промежуточных узлов. Если смотреть со стороны сервиса, то такое подключение будет даже отображаться с другим адресом. Разделение же по протоколам в будущем способно ещё больше усложнить ситуацию.
Такое положение дел, в сетевом смысле, влияет на многие прикладные параметры: “геолокация”, балансировка нагрузки и т.д. Неожиданные эффекты возможны с anycast-узлами, особенно – с CDN, где обычным явлением может стать то, что клиент за HTML-разметкой приходит в один дата-центр, а за файлами изображений и трансляцией видео – в совсем другой, да ещё и с разными IP-адресами источника. Не менее странные эффекты происходят со стороны DNS, когда на авторитативные серверы пользователь приходит из одного региона, а на сам сервис, заходя уже через VPN, из совсем другого. Можно было бы этому пользователю выдать для подключения узлы, которые ближе к точке выхода VPN, но сделать это сложнее. Это влияет на эффективные сетевые задержки: например, по одному пути – 30 ms, по другому – 300 ms, и всё это для одного и того же пользователя веб-сервиса в рамках одной сессии.
Расщепление Сети по уровням приложений прямо влияет на процесс статистических измерений в вебе, в том числе и на развитые системы веб-аналитики. Здесь не только теряется большая доля смысла геопривязки пользователя по IP-адресам, но, более того, так как разные элементы одной и той же страницы могут приходить к пользователю через существенно различающиеся между собой сети, показатели сессии размываются. Например, ряд методов измерений в вебе предполагает [5] использование “праймера” – это специальный Javascript-код (JS), исполняемый в браузере. Возможно, что данный JS поступает к пользователю через VPN, но другие измеряемые параметры, связанные с DNS, – уже через “обычное” подключение. С одной стороны, такая ситуация запутывает результаты, но с другой – именно подобное расщепление может послужить инструментом определения степени “перемешивания” уровней подключения на устройстве пользователя, что, теоретически, представляет данные для построения уникального профиля устройства: такой-то VPN и такой-то DNS-сервис – сочетание может быть достаточно редким. Поэтому, хоть в отношении VPN (а также ECH и DoH) регулярно говорят о “приватности”, необходимо учитывать, что “разбор” подобных технологий достаточно мощными системами исследования трафика, напротив, может помочь идентифицировать конкретного пользователя. Так что “готовить” современные VPN, прицеливаясь на “приватность”, нужно особенно тщательно (а лучше считать, что приватности там нет).
Интересно, что развитие, соответствующее построению всё новых и новых туннелей, оказывается не таким уж и односторонним. Например, в части сервисов DNS уже достаточно давно произошло обратное “просачивание” адресов через слои протоколов: технология под названием EDNS Client Subnet (ECS) позволяет резолверу передать в сторону авторитативного сервера сведения об IP-подсети клиента, который обратился с запросом. То есть авторитативный сервер увидит IP-адресный блок, который соответствует клиенту, находящемуся за резолвером, и это позволит определить провайдера. ECS поддерживается, например, Google Public DNS (и не только). Предполагается, что авторитативный сервер, определив провайдера клиента резолвера, как раз и сможет применить какие-то правила оптимизации. Можно представить, что даже если VPN используется для сокрытия IP-адреса пользовательского подключения, но DNS-сервис напрямую обслуживает DNS-запросы, то наличие ECS в этом DNS-сервисе позволит авторитативным DNS-серверам узнать исходную подсеть. Пример хорошо иллюстрирует принципы перемешивания логики между уровнями и протоколами, но тоже вряд ли соответствует ожиданиям относительно “приватности подключения”.
Один из стратегических выводов, которые можно сделать, наблюдая за “прорытием” всё новых и новых туннелей-протоколов, такой: в ближайшей перспективе возможно разделение большой Сети не только на “региональные сегменты”, но и на интернеты “уровня приложений”. Так, возможное инкапсулирование внутрь туннелей систем адресации (что отчасти намечено в ECH) грозит возникновением дополнительной “маршрутизации” (в принципе, такие решения сегодня имеются внутри крупнейших провайдеров уровня Google). Пользователь станет подключаться через выбранное приложение к некоторой условной наложенной сети, в которой ему будет выводиться представление Интернета, собранное через прокси и точки выхода того сервиса “приватности”, к которому этот пользователь подключается. А снаружи останется динамическое перемешивание сессий между уровнями, как основной способ сокрытия не только состава трафика, но и самого факта доступа к каким-то внешним ресурсам. На десктопе в качестве вероятного способа технической реализации можно отметить сочетание браузера и встроенного в браузер VPN-клиента от соответствующего поставщику браузера VPN-сервиса.
Немалое значение для возникновения перемешивающих туннелей имеет и такая особенность современного Интернета, как изменяющаяся прозрачность относительно разных протоколов. Речь о том, что из конца в конец подключения могут доходить отдельные пакеты, но при этом промежуточные узлы-инспекторы не пропускают трафик конкретного протокола. То есть, если в простом случае признаком для блокирования мог являться IP-адрес, сочетание IP-адреса с номером порта, то более развитые системы смотрят на контекст сессии, который находится выше уровня пакетов (DPI), и действуют по признакам обнаружения высокоуровневых (относительно IP) протоколов, будь то, к примеру, OpenVPN или TLS заданной версии с подозрительными ECH-расширениями.
Раньше подобные решения встречались на рубежах корпоративных сетей, а не в “межсетевом” пространстве, как сейчас. Причём влияние “промежуточных коробочек” (middle boxes), рассматриваемых как “чёрный ящик”, проявляется разными способами, иногда весьма техничными. Так, в спецификации TLS 1.3 сохранился совершенно бесполезный для данной версии сигнал ChangeCipherSpec (CCS), который “промежуточные коробочки” в предыдущих версиях могли использовать в качестве признака установленной TLS-сессии, не пропуская, таким образом, TLS-трафик версии 1.3 без CCS. То есть в новый протокол добавили пустой сигнал (в 1.3 CCS игнорируется) только для того, чтобы последовательность флагов соответствовала сложившимся сигнатурам “обобщённого TLS”. Это пример подхода, когда “что-то непонятное” не пропускает промежуточный узел-фильтр, а пропускает только те сессии, для которых удалось обнаружить сигнатуру.
С одной стороны, современный полностью зашифрованный протокол туннелирования может быть спроектирован так, что его сессии не будут иметь сигнатур вообще: при наличии общего секрета на двух сторонах создаваемого туннеля даже процедуры аутентификации и согласования параметров могут выглядеть как обмен пакетами (например, UDP) случайной длины со случайными данными внутри. С другой стороны, если промежуточные узлы пропускают только трафик с сигнатурой по списку, такая неизвестная сессия обречена на прерывание, но, скорее всего, не на первых пакетах. Как раз этот момент и создаёт базу для использования – при создании совсем уж специальных туннелей – протоколов, внешний вид трафика которых вычислительно неотличим от случайных пакетов (что бы это ни значило). А те варианты доступа к скрытым сервисам, которые создаются в надежде на длительные сессии с непрерывным и широким потоком данных, вынуждены вкладываться в протоколы с хорошо узнаваемыми сигнатурами (типа TLS в варианте HTTPS).
Сегментация современной глобальной Сети происходит не только в параллельных плоскостях, находящихся на разных уровнях (привычные транспорты и приложения, работающие поверх них), но и в “перпендикулярных плоскостях”, когда протоколы туннелируются между транспортами через приложения. Но это добавляет сложности для всех сторон, участвующих в процессе. Технологии туннелирования набирают популярность. Теперь это не просто некие “обобщённые VPN”, но и DNS-over-TLS, DNS-over-HTTPS, а также другие решения из разряда ECH, прямо связанные с уровнем приложений. В области VPN и туннелей растёт распространённость скрытых точек входа и скрытых сервисов. Всё это создаёт новые измерения для перемешивания логики соединений, а привычный описательный подход “узел-канал-узел” больше не работает.
Литература:
[1] https://blog.cloudflare.com/announcing-encrypted-client-hello/
[2] https://groups.google.com/a/mozilla.org/g/dev-platform/c/uv7PNrHUagA/m/BNA4G8fOAAAJ
[3] https://chromestatus.com/feature/6196703843581952
[4] https://tcinet.ru/press-centre/articles/7563/
[5] https://ii.org.ru/dns-kak-istochnik-globalnoy-informacii-o/
Об авторе:
Александр Анатольевич Венедюхин, ведущий аналитик Фонда
развития сетевых технологий «ИнДата»