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

Всякий художник может нарисовать зайца. Дюрер нарисовал зайца. Верно ли, что всякий заяц нарисован Дюрером? Нет, не верно, потому что даже заяц Дюрера нарисован красками.

Традиционная записка к Новому году. WordPress показывает, что на dxdt.ru сейчас опубликовано 2646 записок. Это означает, что получился некоторый прирост по сравнению с прошлым годом. Несколько ссылок:

• О визире и слоне
• Падение тел в физике Аристотеля
• Браузеры и перехват TLS без участия УЦ

С наступающим Новым годом! Спасибо, что читаете.

Добавил (некоторое время назад) в DNS-зону dxdt.ru HTTPS-запись. Название записи может показаться странным в контексте DNS, тем не менее, именно так новая запись, описанная в черновике RFC, и называется. Я кратко упоминал эту запись в статье об использовании DNS для публикации вспомогательной информации:

Например, идёт работа над черновиком (draft) спецификации для DNS-записей с рабочим названием SVCB/HTTPS. Предполагается, что эти записи будут использоваться для публикации данных, определяющих начальные настройки доступа к интернет-ресурсам под данным доменным именем. Отличие от уже имеющихся типов записей (например, от адресных записей) весьма существенное: записи SVCB/HTTPS позволят публиковать сразу набор сведений о нескольких «фронтендах», ответственных за соответствующий сервис (например, веб) под заданным именем; в этот набор включаются разнообразные дополнительные параметры, например, определяющие нестандартные номера портов TCP/UDP, на которых отвечают серверы, или криптографические ключи, позволяющие установить соединение со скрытым сервисом.

Так как dxdt.ru не использует сложных настроек и каких-то дополнительных сервисов для доставки веб-страниц, то и соответствующая HTTPS-запись получилась максимально простой: она всего лишь информирует, что к веб-узлу следует сразу подключаться по HTTPS. То есть, клиент, который поддерживает SVCB/HTTPS, при получении ссылки на сайт с протоколом HTTP, не будет пытаться установить небезопасное подключение, чтобы прочитать HTTP-перенаправление на HTTPS, а сразу использует безопасный протокол. По крайней мере, такова цель размещения HTTPS-записи – реально, мало кто их пока что поддерживает.

А основные SVCB-записи, конечно, гораздо богаче по предоставляемым возможностям. В основном, из-за того, что позволяют публиковать криптографические ключи и сведения о точках входа, которые могут быть использованы для установления соединения в режиме “максимального сокрытия” метаинформации. Это развитие технологии ESNI.

В продолжение заметки про TLS-сертификаты и роль Certificate Transparency. Конечно, наличие меток логов Certificate Transparency может служить в качестве дополнительного признака при валидации сертификата браузером. Однако нужно учитывать тот факт, что сама по себе корректная SCT-метка в сертификате вовсе не означает, что данный сертификат был добавлен в лог. Дело в том, что для получения корректной метки достаточно знать сам исходный сертификат (чтобы вычислить значение хеш-функции) и знать секретный ключ лога (чтобы вычислить значение подписи). Собственно, сами SCT-метки появились для того, чтобы отделить вычислительно сложный процесс добавления сертификата в лог от процесса создания метки, предназначенной для включения в сертификат. Согласно планам применения, наличие метки означает, что оператор лога видел сертификат (и должен включить его в лог, иначе оператор нарушает некоторые правила). Если же посмотреть на этот процесс строго, то наличие метки в сертификате означает, что сертификат видела сторона, знающая секретный ключ лога. Поэтому, если клиентская программа, – например, браузер, – не проверяет наличие сертификата непосредственно в логе, а полагается лишь на корректную SCT-метку, полученную в сертификате, то и проверяет такая программа только дополнительную подпись на сертификате, не более того. То есть, для выпуска валидного сертификата с валидной меткой, стороне, которая выпускает такой сертификат, потребуется доступ к двум ключам – удостоверяющего центра и оператора лога (и не обязательно, что эти две роли играют совершенно разные организации). Не более того.

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

Десять лет назад, 9 декабря 2012 года, на dxdt.ru появилась заметка-прогноз о дронах-наблюдателях в крупных мегаполисах: “летающие роботы, дроны, также оснащённые камерами и патрулирующие в определённых районах, а также, что самое интересное, следующие за какими-то там “подозрительными лицами”. Это всё тщательно описано в фантастических произведениях”.

Что тут можно заметить? Например, что такие дроны стали массово использоваться где-то в 2020 году. Сейчас, в конце 2022 года, подобными сообщениями в новостях СМИ никого уже не удивить. В заметке обозначен 2018 год, так что довольно точно совпало.

– Почему криптосистема называется X25519, откуда это 25519?
– Потому что там присутствует 2^255 и 19. Вот только “плюс” или “минус”? А, понятно, конечно, “минус”, поскольку 2^255+19 делится на 3, что очевидно.

Число, являющееся “модулем” в данной криптосистеме, должно быть простым. Соответственно, 2^255 – 19. Но выбор в большей степени обусловлен тем, что такое число имеет удобное двоичное представление: там много единичных битов подряд. Тем не менее, из наблюдения про 2^255 + 19 можно сделать задачу к Новому году: докажите, что 2^2023 + 2023 делится на три.

(Решение: записка и комментарии ниже.)

На тестовом сервере TLS 1.3, который я реализовал и некоторое время поддерживаю по адресу tls13.1d.pw, пришлось тоже перейти на TLS-сертификаты Let’s Encrypt. А это привело к замене цепочки с ECDSA на цепочку с RSA, что, конечно, не очень хорошо. Вообще, так как сервер экспериментальный и полностью самописный, замена сертификатов требует ручного вмешательства, поэтому “долгие” сертификаты удобнее, чем трёхмесячные. Но, в принципе, можно процесс автоматизировать.

Я как-то перестал описывать изменения тестового сервера на dxdt.ru: прошлая записка на эту тему датирована январём 2020 года. При этом сервер продолжают использовать, он даже помогает находить ошибки и неточности в реализациях TLS стороны клиента. Конечно, ошибки обнаруживаются и в самом сервере – их я стараюсь исправлять.

Добавил несколько записок, вышедших в 2022 году, в раздел “Избранное“:

• О визире и слоне
• Модели движения Земли и знания о них
• Триплеты из цифр и системы счисления
• Падение тел в физике Аристотеля
• Нейросети из пикселей

Иногда открытый ключ нужно буквально вводить руками, например, через “воздушный зазор”. Открытый ключ в ECDSA (и, кстати, в ГОСТ-подписи, но не только там) – это точка на кривой, заданной в параметрах. Речь тут про кривые, используемые в криптосистемах на практике, например, P-256. Координаты точки – это два числа X, Y (сторого говоря, два элемента соответствующего конечного поля, но это технические детали). Если разрядность 256 бит, то может показаться, что для передачи ключа придётся руками вводить 2*32 == 64 байта, что в hextext составит аж 128 знаков. Однако обычно можно ограничиться одной координатой X, а Y – вычислить из уравнения кривой. Такой способ кодирования называется сжатым представлением ключа. Единственная хитрость в том, что, так как в уравнение кривой Y входит в квадрате, координат, соответствующих данному X, пара. Это обратные по сложению элементы (всем привычные +/-). Поэтому нужно передать знак элемента, но для передачи знака достаточно одного дополнительного бита. Поэтому сжатое представление в два раза короче, но “разрядность ключа” при этом никак не страдает (страдают вычислительные затраты на принимающей ключ стороне, но этим часто можно пренебречь; иногда, впрочем, приключаются проблемы с обработкой заведомо неверных значений). Кстати, по этим же причинам ключи криптосистем с ed25519 короче в записи – они изначально “в сжатой форме”.

Число 131312346912764927346012345012378501237411298750981000000001, случайно набранное для проверки программы, оказалось простым. Впрочем, оно не очень большое.

Некоторое время назад я написал утилиту, кодирующую произвольные байтовые значения в строки англосаксонских рун. Используется кодирование, эквивалентное Base32, но с алфавитом из рун. Алфавит, понятно, может быть любым, но в случае рун для отображения в привычных компьютерных системах потребуется поддержка Unicode.

Таблицы Unicode – весьма богатое нововведение. Unicode позволяет записывать в тексте числа древними шумерскими цифрами, вот так: 𒁹 𒌍𒐋 𒌋𒌋𒐈. (Если на вашем устройстве эти цифры не отображаются, то, вероятно, устройство не содержит подходящих шрифтов; такое всё ещё возможно; более того, мне пришлось столкнуться с существенными трудностями при размещении этой записки в WordPress – стандартный редактор данной CMS отказывался принимать соответствующие символы, пришлось применять некоторые хитрости.)

В принципе, шумерская (вавилонская) система записи – позиционная, по основанию 60, но имеет свои особенности, создающие неоднозначности при интерпретации: там используется плавающая “шестидесятеричная точка”, которая не обозначается; кроме того, в классическом варианте, нет цифры для нуля. 𒁹 𒌍𒐋 𒌋𒌋𒐈, в зависимости от контекста, можно интерпретировать не только очевидным способом, как 5783 (1*60^2 + 36*60 + 23), но и, например, как 96.38333(3) (1*60 + 36 + 23/60). Клинописные цифры, соответствующие числам от 1 до 59, записывались засечками; так, 𒐈 – это 3, а 𒌋𒌋 – это 2*10, то есть, 20 (𒌋 обозначает 10). Unicode, – по крайней мере, в теории, – позволяет все эти засечки напечатать и вывести на экран компьютера в виде текста, благодаря наличию разнообразных кодовых таблиц, среди которых есть и таблица с шумерскими древними цифрами.

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

В ноябре 2012 года, десять лет назад, регистраторы RU-CENTER и R01 включили поддержку DNSSEC для имён в доменных зонах .su, .com, .net. В этом перечне важен домен .su – открытое внедрение DNSSEC в российских реестрах началось именно с него. А включение поддержки означало, что все клиенты даных регистраторов смогут настроить DNSSEC для своих зон. (К сожалению, за прошедшие десять лет слишком многое изменилось, а в результате перемен – утрачена масса полезных исторических веб-страниц, поэтому не могу привести ссылку на текст исходной новости; впрочем, копию пока что можно найти в web.archive.ru.)

Вообще, если посмотреть на сайт под доменом nox.su, то там сказано, что “криптографическая информация, соответствующая домену nox.su, внесена в файл зоны .su 23.11.2011” – то есть, ровно 11 лет назад и годом ранее, чем доступ к DNSSEC появился у упомянутых регистраторов. Это объясняется тем, что с nox.su мне помогли специалисты ТЦИ и RU-CENTER (большая им благодарность!): соответствующую DS-запись в реестр внесли, так сказать, в обход общедоступного интерфейса.

За эти годы DNSSEC не обрела особой популярности. Не только в российских доменах, но и во всей глобальной DNS. Сейчас в зоне .ru лишь около 6 тыс. имён с DS-записью (статистика по другим TLD – картину улучшает не сильно). В моде другие направления и другие этапы доставки данных, а в качестве едва ли не единственного метода защиты информации, на прикладном уровне, используется TLS.

Например, если говорить про DNS, то это DoH (DNS-over-HTTPS) и DoT (DNS-over-TLS). Естественно, эти технологии не позволяют, на уровне клиента, проверить подлинность данных именно DNS-ответа, однако делают возможной аутентификацию узла-источника, который эти данные принёс (DNS-резолвер), защищают канал передачи от прослушивания и подмены. Обычно, всё это доступно только на “последней миле” (то есть, от резолвера до клиента). Использование DoH/DoT не отменяет, конечно, возможности проверки DNSSEC, как и не решает основной задачи DNSSEC – подтверждения подлинности адресной информации.