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

ИИ-говорилка GigaChat теперь, как бы, умеет английский язык, однако на все запросы через Telegram-бот, потенциально ведущие к показательному “запутыванию контекста”, отвечает в стиле, что “на эти темы не могу разговаривать” (на русском, кстати). В английском, из-за аналитических свойств языка, запутывать контексты LLM заметно сложнее, чем в русском, но тоже можно (простой пример из области ИТ или, другими словами, из речного хозяйства – bank и log, что в не слишком “грамматической” версии для LLM может, например, выглядеть так: “Having logs removed in timely manner keeps bank totally speckless”). Кстати, в английском неплохо помогают гладкие переключения существительное/глагол. Но, конечно, если подозрительные ветки закрываются системным барьером, то и увидеть ничего нельзя. Впрочем, наличие однотипного ответа тоже демонстрирует уровень “интеллекта”.

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

Включение DNSSEC для dxdt.ru позволило получить максимальный рейтинг 100/100 на сервисе audit.statdom.ru – см. скриншот ниже. (Оговорка: я имею самое непосредственное отношение к разработке данного сервиса, так что, конечно, я заранее знал, что будет 100/100, но тем не менее.)

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

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

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

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

Популярность технологии DNSSEC сейчас резко возросла. Это просто временный пик интереса, и тем не менее я вернул DNSSEC в зону dxdt.ru, где подписей и защищённого делегирования не было с 27/03/2022, почти что два года. Не факт, что DNSSEC надолго, но пока что работает.

(Картинка: DNSViz)

(Кстати, на картинке DNSViz пишет, что ключи имеют разрядность 512 бит, но в реальности это ECDSA на кривой P-256, то есть, “криптографическая” разрядность там 256 бит, конечно. 512 выходит из-за того, что ключ записывается в виде пары координат, а каждый элемент пары – 256-битный, и почему-то авторы DNSViz решили указывать именно разрядность записи.)

Дополнение: на сайте ТЦИ – есть моя статья о 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 сейчас верные.