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

Свежий занятный пример про утечку данных о пользовательской VPN-сессии через DNS, а также и про то, как именно один и тот же пользователь (клиент) может к DNS и к веб-серверу одного и того же сервиса приходить из совсем разных точек Сети: пишут, что клиентская программа VPN-провайдера ExpressVPN длительное время допускала DNS-запросы к локальному, провайдерскому DNS-резолверу, а не к резолверу внутри VPN. О подобных утечках, связанных с DNS, я писал достаточно много, например, в недавней записке про ECS.

У DNSSEC свои особенности. Так, эта технология вносит в древовидную структуру глобальной DNS хрупкость. Дело в том, что “обычная” DNS мало восприимчива к дефектам и ошибкам в реализации, а вот DNS с DNSSEC, из-за свойств используемой криптографии, напротив – очень сильно восприимчива. И древовидная структура тут только усиливает всякую проблему: авария в одной вершине дерева может привести к обрушению кучи ветвей.

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

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

Будущее DNSSEC остаётся туманным.

Добавил в DNS-зону dnssec.pw, которая из недавней записки про совпадающие теги (KeyTag), несколько дополнительных ключей и подписей, чтобы создать минимальное разнообразие криптосистем: была только RSA, добавил ECDSA на P-256, плюс ECDSA KSK (ключ для подписывания ключей) с тегом 12345, как у прочих (кроме SEP-ключа). В общем, ключей теперь много, так что зона разрослась. Зато несколько удобнее тестировать приложения. (Кстати, в зоне сейчас нет A-записей; кроме DNSSEC-записей там только SOA и NS, возможно, другие записи появятся позже.)

Цитата из моей недавней статьи, опубликованной в журнале “Интернет изнутри”:

С одной стороны, современный полностью зашифрованный протокол туннелирования может быть спроектирован так, что его сессии не будут иметь сигнатур вообще: при наличии общего секрета на двух сторонах создаваемого туннеля даже процедуры аутентификации и согласования параметров могут выглядеть как обмен пакетами (например, UDP) случайной длины со случайными данными внутри. С другой стороны, если промежуточные узлы пропускают только трафик с сигнатурой по списку, такая неизвестная сессия обречена на прерывание, но, скорее всего, не на первых пакетах. Как раз этот момент и создаёт базу для использования – при создании совсем уж специальных туннелей – протоколов, внешний вид трафика которых вычислительно неотличим от случайных пакетов (что бы это ни значило). А те варианты доступа к скрытым сервисам, которые создаются в надежде на длительные сессии с непрерывным и широким потоком данных, вынуждены вкладываться в протоколы с хорошо узнаваемыми сигнатурами (типа TLS в варианте HTTPS).

(Я писал об этом на dxdt.ru тоже, конечно.)

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.

Немного занимательной математики и глобальной DNS.

Насколько велика вероятность, что в доменах первого уровня глобальной DNS совпадут теги разных ключей DNSSEC? Нередко приходится слышать, что так как тег 16-битный, то и вероятность, примерно, 1/65535 (за вычетом особенностей алгоритма вычисления значения тега и пр.). Это не верно. Если рассматривать совпадения внутри набора ключей DNS, то получаем хрестоматийный пример парадокса дней рождения: нам не важно, чтобы повторилось конкретное, заданное значение тега, напротив – требуется совпадение любого значения внутри любой пары, а это совсем другая история, поскольку количество всевозможных пар велико даже в небольших наборах ключей. Поэтому вероятность совпадения тегов DNSSEC-ключей, на практике, очень велика. Иногда ключи просто обязательно совпадут по тегам. Например, в списке доменов первого уровня (корневой зоны DNS) сейчас 1452 имени, то есть, можно составить 1053426 пар (больше миллиона). А это количество (практически) гарантирует, что будут совпадения тегов ключей.

И действительно, если собрать DNSKEY-записи из доменов первого уровня, то окажется, что значений повторяющихся тегов, – то есть, значений, которые встречаются для разных ключей в разных зонах, – сильно больше сотни: у меня получилось 129 таких тегов. Обратите, кстати, внимание, что некоторые ключи разных зон TLD имеют одинаковые теги потому, что это просто одинаковые ключи. Такие повторы отбрасывались. Потому что корректно – сравнивать именно сами значения ключей (как и в прочих случаях использования тегов). Например, различные DNSSEC-ключи с одинаковыми тегами опубликованы в зонах cab и today, в зонах agency, weber и temasek, и во многих других.

(Дополнение: естественно, выше предполагается, что ключи для различных зон генерируются независимо, случайным образом.)

DNSSEC-подписи, удостоверяющие адресную информацию, размещаются в RRSIG-записях. Ссылка на открытый ключ, нужный для проверки подписи, в RRSIG записывается в виде 16-битного тега (KeyTag), который вычисляется по достаточно простому алгоритму от данных ключа. Соответственно, ключи публикуются в DNSKEY-записях. Можно ли специально подобрать несколько валидных ключей так, чтобы у них были одинаковые теги? Очевидно – можно (ключей много больше, чем тегов). И подбор совсем нетрудно сделать. Более того – даже сохранятся валидные подписи и, условная, “корректность” зоны с точки зрения DNSSEC. “Корректность” тут в кавычках потому, что, вообще говоря, несколько ключей с одинаковыми тегами не должны бы присутствовать в DNS-зоне, поскольку это нарушает логику ссылок из RRSIG. И хорошо бы в таком случае выводить ошибку валидации, но возможен более мягкий подход, который и используется.

Посмотрите, в качестве примера, на DNS-зону dnssec.pw – там я разместил несколько ключей (ZSK – Zone Signing Key), которые имеют одинаковые теги со значением 12345. Два ключа из четырёх ZSK задействованы в подписывании записей, а поскольку подписи можно проверять методом перебора ключей, то и RRSIG – валидируются, если валидатор резолвера справляется с ситуацией. Пятый ключ – это KSK, точка входа. Схема показана на картинке (ниже), которую сформировал весьма полезный сервис DNSViz. Повторяющиеся идентификаторы (id = 12345) выглядят занятно, однако количество вершин графа соответствует количеству ключей, а рёбра – соответствуют структуре подписей. Так что DNSViz не сломался:

Другой, не менее полезный, сервис для анализа DNSSEC – DNSSEC Analyzer – проверки для данной зоны тоже выполняет корректно, но в таблице результатов совпадающие идентификаторы могут запутать несколько больше, чем на графе GraphViz:

Валидирующие резолверы должны справляться с подобной конфигурацией ключей, однако Google Public DNS (8.8.8.8) возвращает в статусе информацию о “некорректном формате RRSIG”, но ответ всё равно снабжается флагом AD (Authentic Data), обозначающим, что проверка подлинности DNSSEC прошла успешно – впрочем, это соответствует действительности: подписи и цепочка в зоне dnssec.pw сейчас верные.

Официальное сообщение КЦ .RU/.РФ о вчерашней проблеме с DNSSEC: “возникшая коллизия ключей, в причинах которой в настоящее время продолжают разбираться специалисты Технического центра интернет (ТЦИ) и MSK-IX, привела к временной недоступности зоны .RU для части интернет-пользователей”.

Одна из ключевых особенностей DNSSEC в том, что подписываются и данные об отсутствии делегирующих DNSSEC-записей (DS-записи) для зон, находящихся уровнем ниже. Поэтому, если у вас валидирующий резолвер, то проблема с подписями в DNSSEC может затронуть и те зоны, в которых DNSSEC нет. (Кстати, а особенность DNS – в том, что это всеобъемлющая для Интернета (и не только) технология, которую мало кто замечает, пока всё работает.)

В логах веб-сервера dxdt.ru тысячи записей о GET-запросах от некоторого ClaudeBot, как указано в User-Agent. Больше в User-Agent ничего не указано, хотя правила хорошего тона предполагают, как минимум, ссылку на страницу с описанием того, “что это, зачем и как оно приходит” – в HTTP это нетрудно сделать. Конечно, в User-Agent каждый может написать что вздумает, но данный ClaudeBot ещё и приходит за одними и теми же страницами (которые не изменялись), постоянно переключая IP-адреса. А IP-адреса там из пула AWS (амазоновский сервис), поэтому даже и обратная зона мало о чем говорит (ну, кроме того, что это AWS). Непонятно, имеют ли следы в логах, оставленные данным ботом, какое-то отношение к деятельности одноимённого продукта очередной AI/ИИ-компании, решения которой для российских пользователей заблокированы, но забавно уже то, что имя используется совпадающее; тем более, что на сайте компании не удалось найти ничего о том, как их боты оформляют свои запросы.

Между прочим, один из простых примеров того, что для успешной сегментации интернетов требуется техническая централизация – это установка внешних сервисов капчи (обычно, от Google) на сайты интернет-магазинов, в том числе, крупных магазинов Рунета, как бы для “защиты” формы логина. То есть, администраторы, вероятно, полагают, что “защитили форму от ботов”, но на самом-то деле – они предоставили внешнему провайдеру, тому же Google, возможность единолично решать, какие пользователи могут заходить на сайт этого магазина, а какие – не могут. То есть, передали центральному сервису, который магазином никак не контролируется и действует в своих интересах, возможность сегментировать пользователей этого магазина.