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

Интересный практический пример неверной настройки DNS в зоне vk.com, как его можно видеть и сейчас, и уже в течение нескольких недель. Скриншот выдачи сервиса проверки audit.statdom.ru (подробные объяснения – ниже):

Зона vk.com делегирована на авторитативные NS с именами, находящимися в той же зоне (так называемые “субординатные” NS), а именно: ns1, ns2, ns3, ns4.vk.com (всё в vk.com, не лучшее решение, но сейчас о другом). При этом в самой зоне vk.com для имён NS указаны AAAA-записи – это DNS-записи, содержащие IPv6-адреса. Вообще, чтобы избежать циклов при рекурсивном опросе DNS, для имён авторитативных серверов, которые сами определены в делегируемой зоне, используются так называемые glue-записи: серверы имён вышестоящей зоны возвращают IP-адреса для имён, на которые эта зона делегирована.

То есть, если домен example.com делегирован на ns1.example.com и ns2.example.com, то авторитативные серверы зоны первого уровня com. будут возвращать в дополнительном блоке DNS-ответа IP-адреса для ns1.example.com и ns2.example.com, чтобы резолвер мог к ним обратиться. (Понятно, что иначе резолвер, для определения адреса ns1.example.com, должен обратиться к DNS-серверам example.com, а чтобы обратиться к DNS-серверам example.com – нужно узнать адрес ns1.example.com, ну и так далее.)

Так вот, для vk.com в glue- указаны только А-записи (IPv4-адреса), но не указаны AAAA-записи (IPv6-адреса). Между тем, как отмечено в предыдущем параграфе, в самой зоне IPv6-адреса для NS указаны: каждый NS из списка делегирования снабжён v6-адресом в DNS. Под “данными в самой зоне” тут имеются в виду данные, возвращаемые непосредственно авторитативными NSами (которые ns[1,2,3,4].vk.com).

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

Для vk.com дополнительными оказываются адреса IPv6 для авторитативных NS. Адреса выбраны красивые, резолверы, работающие по v6, могли бы их использовать, но DNS-сервис под ними недоступен и отсутствуют glue-записи.

Не нужно забывать, что ключевую роль в процессе сегментации интернетов сыграло желание слово “Интернет” писать со строчной буквы.

Гибридная криптосистема с постквантовой стойкостью X25519Kyber768 использует, как нетрудно догадаться, ключи X25519 в дополнение к Kyber. При этом X25519 – типовая криптосистема в современном TLS, так что в одном и том же ClientHello может быть одновременно два ключа: и X25519Kyber768, и просто X25519. И вот, например, Firefox в свежих версиях использует тут один и тот же ключ X25519 – и в гибриде, и в обособленном варианте. Это экономит одну итерацию X25519 (технически, что в гибридном варианте, что нет – это одна и та же криптосистема, никаких отличий). А вот Chrome, в такой же ситуации, использует два разных ключа X25519.

Снова пишут о том, что пользователи TOR могут быть “деанонимизированы” при помощи анализа параметров трафика с сопоставлением по времени. Почему-то, иногда такая особенность преподносится как новость. Но это весьма старый метод. Например, я писал об этом почти десять лет назад на dxdt.ru:

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

P.S. В той записке есть ссылки на два внешних ресурса: PDF с исходным описанием на сайте издания Spiegel и ссылка на сайт журнала “Доменные имена”, в котором я публиковал статью по теме. Показательно, что ни одна из ссылок нынче не ведёт на документы и тексты: обращение по адресу на сайте издания Spiegel – возвращает HTTP 404, а ссылка на сайт “Доменных имён” – переадресует на главную страницу nic.ru. В последнем случае, это связано с тем, что RU-CENTER вообще удалил сайт журнала – мне до сих пор непонятно по какой такой причине, поскольку, хоть сам журнал и закрыли, но на сайте был весьма полезный архив номеров.

Использование имеющихся сейчас посквантовых криптосистем в TLS существенно увеличивает объём передаваемых данных. Например, ключ Kyber768, используемый в первом же сообщении (ClientHello), требует более килобайта (1184 байта). При этом, в TLS 1.3 есть штатная возможность передать несколько ключей для разных криптосистем в одном сообщении ClientHello, чтобы сервер выбрал подходящее. Эта возможность постоянно используется на практике.

Например, клиент может сразу передать ключи X25519 (32 байта) и P-256 (32+32 == 64 байта). То есть, две криптосистемы – и лишь 96 байтов расходуется на запись ключей (небольшое количество дополнительных байтов нужно для записи тех структур, в которых передаются ключи, но это можно не учитывать). Если передавать ключи двух постквантовых криптосистем, – скажем, с теми же Kyber768 и стандартизованным вариантом ML-KEM, – то получается уже больше двух килобайт. Это много, но если регулярно переходить от одной поствкантовой криптосистемы к другой, то становится необходимым, рутинным элементом TLS-соединений. Заметьте, что сам перечень поддерживаемых клиентом криптосистем для обмена сессионными секретами передаётся в TLS отдельно. Обычно, в этом перечне указано значительно больше криптосистем, чем передано ключей. Так, браузер может передавать семь поддерживаемых вариантов и ключи только для трёх из них (так сейчас делает Firefox). Чтобы сервер мог выбрать криптосистему, ключи от которой отсутствуют в ClientHello, в TLS 1.3 предусмотрен механизм повторного согласования – HelloRetryRequest: сервер, в этом случае, запрашивает повторное ClientHello, где будет только ключ той криптосистемы, которая выбрана (это всё можно самостоятельно увидеть на тестовом сервере TLS 1.3 при помощи современного браузера).

Подобный перебор с постквантовыми криптосистемами ещё больше увеличивает трафик, поэтому уже рассматриваются варианты того, как бы данный момент переложить на DNS. Так, в сообщении Google про ML-KEM в браузере Chrome, на которое я недавно ссылался, упоминается соответствующий черновик RFC – там предлагается публиковать в DNS сведения о предпочитаемых криптосистемах для обмена сеансовыми ключами в TLS. Конечно, тут нужно учитывать возможную защиту DNS-ответов от подмены, то есть, всё это тянет за собой не только и не столько DNSSEC (которая сама не имеет пока что ничего “постквантового”), как DNS-over-TLS/DNS-over-HTTPS.

Развитие постквантового TLS очень бурное. Впрочем, пока что не совсем понятно, для чего вообще такой рост объёмов данных. Сама по себе “постквантовая стойкость” тут ничего не объясняет, как и популярные описания в стиле “зашифруй заранее, пока нет квантового компьютера”. Однако вот уже и DNS охвачена дополнением записей. С одной стороны, размещение предварительных сведений о настройках TLS в DNS выглядит более чем разумно: запрос в систему всё равно необходим для получения IP-адреса; с другой стороны – данное направление развития как-то быстро сводится к надстраиванию новых и новых, всё больших и больших “дополнений”. (Надстраивание происходит в ускоряющемся темпе: не успели год назад внедрить в браузеры Kyber, как его уже переименовали в ML-KEM и переделали.) Эти “дополнения” вытесняют привычную работу с DNS, заменяя её на другой процесс, который следует называть “обнаружением сервисов” (Service Discovery) – дело в том, что с появлением ECH даже и IP-адреса будут извлекаться из доступной сети по-другому.

Google пишет, что в ближайших версиях Chrome отключит использование Kyber768, заменив его на ML-KEM. Речь про использование в гибридной криптосистеме с постквантовой стойкостью для обмена ключами TLS 1.3. То есть, вместо X25519+Kyber768 будет ML-KEM+X25519 (здесь “минус” это дефис, а “плюс” – это плюс). Связано решение с тем, что криптосистему, в постквантовой части, стандартизировал NIST, и вариант из стандарта (кто бы мог подумать!) не совместим с тем вариантом, который использовался до стандартизации под именем Kyber.

В частности, при стандартизации отказались от одного из “промежуточных” преобразований с хеш-функцией, которое, в теории, могло бы предотвращать утечки состояния генератора (псевдо)случайных чисел. Про это всё, естественно, написано в документе NIST. Формулировка выглядит занимательно для тех, кто следит за темой модификации криптосистем в стандартах. В цитате далее (из приложения к стандарту NIST) под словосочетанием “этот шаг” (this step) имеется в виду шаг алгоритма, на котором вычислялось значение SHA-256 от инициализирующего значения: “The purpose of this step was to safeguard against the use of flawed randomness generation processes. As this standard requires the use of NIST-approved randomness generation, this step is unnecessary and is not performed in ML-KEM”. Пересказ смысла: поскольку в стандарте NIST прописано требование использовать только генераторы случайных чисел, разрешённые NIST, то и дополнительная защита от “испорченных генераторов” (то есть, оборачивание значения в хеш-функцию) более и не требуется. Логично, чего уж там. Строго говоря, ничто не мешает применить хеш-функцию для маскировки состояния раньше, до передачи значения в KEM. (Тут, конечно, речь только про дополнительный шаг уровня реализации, а SHA-3, требуемая непосредственно внутри Kyber, осталась.)

Так что постквантовые криптосистемы не просто развиваются, но ещё и вот начали тасоваться их названия, порядок байтов, способы конкатенации и использования хеш-функций. Возможно, я через некоторое время добавлю ML-KEM+X25519 на свой тестовый сервер TLS 1.3.

Минутка специфического интернет-технологического юмора:

A (печатая в консоли, случайно склеивает два IP-адреса, вот так: 192.168.11.12192.168.12.11.).
B (наблюдая за процессом, пишет в чат): Это был адрес в формате IPv010.
A: Почему десять?
B: Потому что два IPv4 склеились – то есть, четыре плюс четыре.
A: Тогда должно быть IP-8.
B: Вот я и пишу: IPv010.

Иногда спрашивают: почему (некоторые) УЦ TLS не поддерживают подтверждение права управления доменом с использованием WHOIS-запросов? Вот появился очередной практический пример, иллюстрирующий, почему тут не нужно использовать WHOIS ни в каком виде: исследователи зарегистрировали домен, ранее служивший хостнеймом для whois-сервиса зоны .MOBI, и, как утверждается, получили потенциальную возможность подтверждать право управления доменом по запросам от УЦ, подставляя произвольный адрес e-mail в ответ (“потенциальную” – потому что сертификат исследователи заказывать не стали).

Подтверждение (валидация) права управления доменом (DCV – Domain Control Validation) – основа процесса выпуска TLS-сертификатов публичным УЦ. Понятно, что и ответы из WHOIS должны дополнительно валидироваться, и актуальность хостнейма сервера – контролироваться. Однако, каждый новый поддерживаемый метод DCV создаёт риски, а особенно велики эти риски, когда метод подразумевает использование дополнительных протоколов. Вообще, для автоматического выполнения DCV сейчас есть только один полностью подходящий способ: публикация TXT-записи с заданным значением в DNS. Но и тут имеется куча оговорок, конечно. При этом, уже и близкий метод – HTTP-запрос, – существенно хуже, пусть и использует DNS для передачи A-записей.

Посмотрел, на какой домен можно было бы перенести dxdt.ru (поскольку RU-CENTER усиленно шлёт письма про привязку ЕСИА). Я ранее зарегистрировал несколько подходящих имён в других зонах верхнего уровня (например, .blog), однако и на этом направлении просматриваются проблемы, пусть и другого рода: вполне вероятно, что в скором времени интернет-санкции расширят очередной раз, а в результате – регистратуры (не регистраторы даже) заблокируют домены администраторов с неподходящим “подсанкционным” адресом (как уже было и с хостингами, и со многими иностранными регистраторами). Я недавно писал, что оператор реестра, – регистратура, – не только может отключить доступ регистраторов (уже происходит), но и заблокировать/удалить имена по своему выбору.

В июне этого года я удивлялся, что на сайте ИИ-корпорации SSI даже тег div в коде страницы закрыть не могут, что уже там говорить про добавление DOCTYPE. Уже сегодня эта корпорация получила миллиард финансирования (насколько я понимаю, по меркам данного рынка – не очень много), об этом они написали пару строк на сайте и – чудесным образом – тег div в коде теперь закрыт! (Впрочем, возможно, что и раньше закрыли, не дожидаясь минимального финансирования.) А вот DOCTYPE всё ещё не реализовали.

Занятно, кстати, что моё описание TLS (как я считаю, неплохое, и уж точно очень подробное) отсутствует совсем на первых страницах выдачи Google, даже по специальным, техническим/тематическим запросам. Возможно, в выдаче Google ссылок на него вообще нет. Наверное, бот Google “не осилил много букв”. А вот в “Яндексе” (ya.ru) – ссылки на описание всё ещё присутствуют, и даже нередко на первой странице, что правильно, а поэтому “Яндекс” тут выигрывает (но посмотрим, что будет дальше).