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

Свежий занятный пример про утечку данных о пользовательской 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 сейчас верные.

Как известно, современные мощные смартфоны могут дорисовывать детали на изображения, полученные встроенными камерами. Издание TechRadar цитирует комментарий руководителя Customer Experience компании Samsung, в котором он говорит про глубокую “доработку” с помощью ИИ-фильтров изображений, выводимых камерой новейшего смартфона, обосновывая произвольный уровень такой доработки тем, что настоящих снимков всё равно не существует, в принципе:

There was a debate around what constitutes a real picture. And actually, there is no such thing as a real picture. As soon as you have sensors to capture something, you reproduce [what you’re seeing], and it doesn’t mean anything. There is no real picture. (Шли споры о том, что же является настоящим снимком. И на самом деле – нет такой вещи, как настоящий снимок. Как только вы начинаете использовать сенсоры, чтобы зафиксировать что-то, вы воспроизводите [то, что видите] и это ничего не значит. Нет там настоящего снимка.)

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

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

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

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