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

DNSSEC предоставляет механизм удостоверения адресной информации в DNS, что требует подтверждения факта отсутствия ответа на запрос. Собственно, это особенность не столько DNSSEC, сколько любой подобной криптографической системы: необходима возможность криптографического подтверждения, что какие-то записи действительно отсутствуют, потому что иначе активный аткующий может просто удалить из DNS-ответов записи, обеспечивающие безопасное делегирование (DS-записи), тем самым сымитировав отсутствие DNSSEC в атакуемой зоне. Отсутствию записей и имён в терминах DNS соответствует NXDOMAIN (нет имени) и NODATA (нет данных записи запрошенного типа). NXDOMAIN – это когда спросили имя test.example.com, а его в зоне example.com нет. NODATA – спросили TXT-запись для test.ru, имя test.ru есть, но ему не соответствует TXT-записи (NODATA это ANSWER:0 со статусом NOERROR, если в терминах BIND).

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

Например, для NXDOMAIN “подписываются” два ближайших имени, между которыми оказалось бы запрашиваемое, если все имена в зоне упорядочить. Известно, что эта реализация позволяет третьей стороне проиндексировать имена, существующие в зоне, поскольку ответ на запрос со специально составленным несуществующим именем позволяет видеть соседние существующие имена – это называется DNSSEC zone walking (индексация зоны), и предоставляет хрестоматийный материал для обучения студентов направления “Информационная безопасность”, но не более. Строго говоря, есть два основных варианта решения проблемы “подписывания дыр”: они называются NSEC и NSEC3, а последний предоставляет больше защиты от индексации зоны, однако сейчас это всё лишь иллюстративные детали, поскольку вообще странно считать, будто заведомо публичные записи в зоне должны быть защищены таким странным способом от “обнаружения” – см., впрочем, про “принцип Керкгоффса“. Предложены способы, предотвращающие индексацию зоны путём “подставных” ответов, содержащих специально сгенерированные имена.

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

При полностью динамической работе DNS на стороне авторитативного сервера всякое противодействие индексации зоны требует динамических подписей. Однако в таком случае обработка NXDOMAIN быстро превращается в проблему, поскольку требуются дополнительные вычисления. Особенно, если в зоне много имён. Грубо говоря, если у вас есть миллион записей с именами хостов в некоторой базе данных, то уже для обнаружения соседних имён придётся строить какой-то индекс и так далее. Если же состав записей постоянно изменяется, а ответ зависит и от видимых характеристик клиента, и от текущего состояния большей системы на стороне сервера, то вычисление NXDOMAIN может вылететь в копеечку (в том числе, из-за большого размера ответа с подписями). Оригинальное решение тут первыми применили в Cloudflare, ещё в 2016 году. Решение основано на модификации логики обслуживания DNSSEC – предлагается, фактически, исключить понятие отсутствующего имени или отсутствующей записи, что позволит генерировать виртуальные подписи на лету (но, обратите внимание, это не отменяет кэширования сгенерированных ответов).

Иными словами – сервер выдаёт “нечестные” ответы. Например, сервер не отвечает резолверу со статусом NXDOMAIN вообще, а вместо этого использует вариант NODATA: на запрос о реально не существующем в зоне имени сервер отвечает, что есть имя, состоящее из префикса \000., приписываемого к запрошенному имени, то есть, это как бы граница (которой в реальной зоне нет), а ответ поэтому содержит одну NSEC-запись; подпись же вычисляется на лету. Для случая “настоящего” NODATA – всё работает аналогично: сервер отвечает, что есть все мыслимые ресурсные записи, кроме той, которую запросил резолвер. Например, если резолвер спрашивает A-запись, то авторитативный ответ будет содержать указание в NSEC на существование NS, SOA, TXT, LOC, SRV и прочих DNS-записей, но не A-записи. Это тоже позволяет генерировать ответы динамически. То есть, авторитативный сервер “обманывает” резолвер, но делает это для того, чтобы экономить вычислительные ресурсы (поэтому механизм называется black lie – вместо white lie, однако это детали литературной терминологии).

Всё это несложно сейчас увидеть снаружи на примере Cloudflare: попробуйте взять dig и проверить самостоятельно на той или иной зоне, поддерживающей DNSSEC на авторитативных серверах Cloudflare. Такая реализация не только позволяет работать с динамической DNS, но и экономит место в ответах (другой существенный способ экономии – ECDSA, которую только и использует Cloudflare, так как ECDSA-подписи короче RSA).

Насколько такой метод универсален и эффективен? Для больших, постоянно изменяющихся наборов DNS-данных, эффективен, однако требует программного решения собственной разработки. При этом, если DNS-зона не особенно часто изменяется, то смысла в динамическом вычислении подписей меньше. Для многих зон обычным является изменение содержания DNS-записей, скажем, раз в месяц (или даже раз в год). С другой стороны, динамическая “подмена” NXDOMAIN может защитить от индексации зоны.

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

Кстати, если посмотреть в DNS-зону cloudflare.com (это, понятно, Cloudflare) на предмет политики DMARC, то там в поле rua указан почтовый адрес в cyber.dhs.gov:

$ dig -t TXT _dmarc.cloudflare.com +short
"v=DMARC1; p=reject; pct=100; rua=[...]mailto:reports@dmarc.cyber.dhs.gov"

Что это означает? Имя cyber.dhs.gov – это в Штатах агентство CISA (Cybersecurity and Infrastructure Security Agency), относящееся к DHS, то есть, к министерству внутренней безопасности (Department of Homeland Security). Опция rua в строке DMARC обозначает адрес (адреса), по которому принимающие почтовые серверы могут отправлять отчёты об обработке почтовых сообщений (допускаются разные протоколы для доставки, но обязательный – mailto, электронная почта). Так что, запись означает, что сборщик отчётов DMARC CISA может сразу принимать сведения о получении почты с адресами в домене cloudflare.com. Это не обязательно сообщения, действительно отправленные почтовой системой Cloudflare – может быть и нежелательная рассылка с “подспуфленным” адресом: для обнаружения таких писем как раз нужны DMARC и DKIM.

Немного про административную структуру, связанную с доменами верхнего уровня. Про эту структуру сейчас почему-то забывают, сосредотачиваясь на регистраторах, с которыми взаимодействует обычный пользователь. Однако, в современных интернет-реалиях, эта административная стурктура довольно важна. Домены верхнего уровня здесь – это имена зон, указанные в корневой зоне общепринятой (пока что) системы доменных имён (DNS): .COM, .NET, .RU, .PW, .BAR и др., их сейчас очень много, заметно больше 1500. Корневой зоной всё ещё управляет IANA под эгидой ICANN, но сейчас речь о другом. А именно: практически у всякого домена верхнего уровня есть обособленный администратор, технический контакт и оператор реестра. И это всё могут быть совсем разные организации. (Тут встречаются исключения, конечно, но весьма редкие: “потерявшиеся” зоны, “спорные” зоны, тестовые домены и так далее – эти случаи не рассматриваем.)

Администратор – определяет, как именно управляется домен верхнего уровня: устанавливает правила и т.д. Администратор же выбирает оператора реестра. А вот реестр – это такая специальная база данных, связанная с технической частью DNS, которая содержит сведения о регистрациях имён (в том числе, сведения о регистрантах/администраторах) и, поэтому, служит источником сведений для настроек доменов в качестве пространства сетевых имён внутри доменной зоны.

Административные и технические роли в доменах верхнего уровня могут пересекаться неожиданным образом. Например, что общего у доменов .PW и .BAR? Администраторы – разные. Технические контакты – разные. Даже класс домена отличается: .PW – это домен ccTLD (национальный), а .BAR – это New gTLD (домены, добавленные в DNS силами ICANN в рамках процесса “массового расширения”). Поэтому далеко не всякий продвинутый интернет-пользователь знает, что за этими разными доменами стоит один и тот же провайдер сервисов реестра: компания CentralNic (это, впрочем, и не скрывается).

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

Что это всё означает? Это означает, что если оператор реестра того или иного домена верхнего уровня станет что-то блокировать (по указанию администратора домена или без такого указания), то он может заблокировать передачу регистраций с конкретными данными регистрантов (администраторов доменов уровнем ниже). И регистратор с этим не может ничего сделать. Собственно, регистратора могут просто отключить от реестра, а доменные имена, которые через него зарегистрированы, передать другому регистратору, снять с делегирования (то есть, они не будут доступны в DNS) и перевести в статус “заблокированных”, переделегировать произвольным образом, или просто удалить – вариантов тут масса.

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

В Кембриджском словаре словом 2023 года назвали hallucinate, а в Институте Пушкина – тоже выбрали слово года из области ИИ, однако вариант максимально прозаичный: “нейросеть”. (Сайт института хоть и размещается в оригинальном домене верхнего уровня, но устроен несколько странно: непонятно, как можно сослаться на страницу с конкретным сообщением, поэтому будет ссылка на главную страницу.)

Современные “Яндекс.Рефераты”, конечно, работают несколько лучше, да и результаты забавные:

Насколько прочнее обычного хлопок от шампанского?

YandexGPT2:
Хлопок от шампанского сделан из той же ткани, что и обычная хлопковая ткань. Это не более прочный материал, чем обычный хлопок. Название “хлопок от шампанского” может ввести в заблуждение, так как люди могут подумать, что это особый вид ткани, но на самом деле это просто остатки от производства бутылок шампанского.

Насколько громче обычного хлопок от шампанского?

YandexGPT2:
Хлопок от шампанского создает примерно такой же уровень шума, как и обычный хлопок. Однако, поскольку он более плотный и тяжелый, он может казаться более громким.

А теперь представьте, что, следом за публикациями СМИ и восторженными маркетинговыми объяснениями, подобные генераторы начнут массово использовать для получения “краткого пересказа” текстов, чтобы потом выносить суждения на основе “исследования” компьютерным ИИ. Это ведь даже не распознавание объектов на изображениях.

Вот The Guardian, в статье о новой работе на тему ИИ с успешным перебором, пишут:

A major limiting factor is that the problems need to have solutions that can be verified automatically, which rules out many questions in biology, where hypotheses often need to be tested with lab experiments. (Существенный ограничивающий фактор в том, что проблемы должны иметь решения, которые могут быть проверены автоматически, что исключает многие вопросы биологии, где гипотезы часто должны проверяться лабораторными экспериментами.)

При этом в исходной работе ничего нет про “исключение проблем биологии”. Что, впрочем, не удивительно: речь-то в статье идёт про классические вычислительные NP-полные задачи, для которых, понятно, существует быстрый алгоритм проверки предложенного решения (это по определению). “Лабораторные эксперименты” тут не требуются (а что, кстати, мешает проводить такие эксперименты в автоматическом режиме? ну, особенно сейчас, когда кругом супермощный “искусственный интеллект”?). А в публикации, которая доступна на сайте Nature, на этот раз, кроме обязательного LLM, упоминают генетические алгоритмы.

Сервис “Метасловарь” на новом сайте gramota.ru выдаёт несколько неожиданные, но занимательные, результаты. В прошлый раз в ответ на запрос “ключом” сайт выдал “крючок”. Однако если спросить “крючком“, то в ответе уже будет “крючок” и “клочок”. Если вы думаете, что словарь должен работать только в именительном падеже, да в единственном числе, то это не так для некоторого метасловаря, результаты которого являются центральным элементом страницы, а сам метасловарь настроен по умолчанию на обработку запросов “общего поиска”. И, всё же, вывод словарной статьи про “ключ”, в ответ на запрос “ключом”, выглядит несколько более полезным, чем “крючок”.

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

Построим аппаратную электронную схему (классическую, на каких-нибудь привычных “обобщённых” транзисторах, а не “квантовую”), которая вычисляет экспоненту по модулю заданного числа, достаточно большого. Предположим, что подсчёт при помощи данной аппаратуры, нужный для факторизации этого заданного большого числа, требует выполнения, примерно, 2^2048 операций вычисления экспоненты. Это очень много, но позволяет сломать RSA. Тут возникает вопрос времени, который можно сформулировать несколько неожиданным образом: если это 2^2048 тактов, то можно ли тактировать нашу аппаратную схему на примерно такой же частоте, в тактах в секунду, чтобы вычисления за секунду и закончились? Выглядит абсурдно. А вдруг так можно было? Можно было сделать такой волшебный каскадный задающий генератор, каждый каскад которого увеличивает частоту в два раза, и, начав с мегагерца (или с 2^20), добраться к концу протяжённой схемы до 2^2048 герц (примерно)?

Почему такой подход не работает? Всякий человек, знакомый с реальными электронным схемами, скажет, что аппаратура должна бы перестать генерировать какие-то различимые транзисторами такты несравнимо раньше, чем сигнал вообще доберётся до выходного каскада с расчётными 2^2048 герц. А аппаратная схема “с транзисторами” перестанет работать ещё раньше из-за, так сказать, исчезновения фронтов сигналов: дело даже не в квантах, не в скорости света, а в том, что на соответствующих отрезках времени, если бы их и можно было выразить “в квадратурах”, никаких ЭМ-сигналов просто нет. Но сложность вычислений – есть, а непрерывность времени – подразумевается при переходе к квантовым алгоритмам. Алгоритм Шора использует совпадающую по теоретическим функциональным характеристикам аппаратуру (там тоже вычисляется экспонента). А только что описанная классическая сложность здесь успешно уезжает в непрерывность вероятностей – как известно, в континуум влезает и не такое, да не просто влезает, а ещё можно потом извлечь в несколько раз больше.

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

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

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

Чем, например, хорошо слово “замок”? Тем, что это сбалансированный “токен” – тут для двух веток (механизм и сооружение) можно ожидать примерно одинаковый “вес”: и одно, и другое значение широко применяются в “обычных” текстах.

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

(Update, 04/01/2024: пример успешного переключения “шампанского” и “хлопчатобумажного” на примере GigaChat.)

Кстати, что ещё касается регистраторов и, в частности, GoDaddy. Доменные зоны, а точнее – имена хостов в этих зонах, – часто используются косвенно, в составе тех или иных технических систем. Про это могут забыть даже администраторы и DevOps. Тут могут быть имена авторитативных серверов DNS (NS), имена для почтовых серверов, технические зоны для CDN и прочих систем распределения нагрузки. Потеря подобного имени может привести не только к недоступности ресурсов, но и к той или иной подмене адресации (потому что имя могут перехватить). При этом, GoDaddy мог выступать провайдером DNS-хостинга, что означает появление задач по корректному переносу самой доменной зоны. Так что проблемы у администраторов и DevOps, конечно, могут быть. Особенно, если учитывать, что изменение регистратора доменного имени, даже при содействии отдающей стороны, может занять время: нужно получать коды подтверждения, снимать/устанавливать разные флаги, вести дополнительную переписку. У GoDaddy, например, не самая надёжная и понятная панель управления – часто при переносе имён происходят какие-то загадочные сбои, не отправляются письма.

(И, опять же, не стоит забывать про реестры.)

Про использование QR-кодов в качестве транспорта для различных атак я писал и десять лет назад, и ранее, а сейчас вот тема вдруг обрела дополнительную популярность: СМИ распространяют предупреждения FTC. Процитирую свою записку, вышедшую в 2012 году:

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