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

Что ж, этого следовало ожидать: пишут, что вот и серверные IP-адреса хостинги должны будут раздавать через ЕСИА. Ну, будет очередной повод закрыть остатки сайтов, которые я поддерживаю. Похоже, что и с электронной почтой будет трудновато. Часть сайтов, кстати, что были в .RU/.SU, я уже и так закрыл; но dxdt вот пока перенёс на dxdt.blog. Однако, скорее всего, следующим шагом будет обязательное размещение какого-нибудь JS-кода счётчика на веб-страницах и тому подобные штуки. Поэтому, видимо, не долго-то осталось, так или иначе.

Хотя, в принципе, Интернет уже закончился и так.

Представьте, что дистанционный пользователь некоторого интернет-узла авторизуется по паролю, который ранее создал и запомнил. Сама сессия работы с интернет-узлом защищена TLS (для примера), поэтому пароль передаётся внутри зашифрованного трафика, но в момент сравнения – используется в открытом виде: то есть, сервер видит открытый пароль, а третья сторона, прослушивающая TLS-трафик, видит зашифрованный пароль. Сервер пароль использует прямо только при начальном сравнении, и в серверной базе данных (БД) долговременно сохраняется не пароль, а значение хеш-функции, полученное по алгоритму, стойкому к перебору (типовая практика).

Пусть теперь появился квантовый компьютер, реализующий алгоритм Шора большой разрядности. Этот алогоритм позволяет атаковать асимметричные криптосистемы, в том числе, в TLS. И если TLS-сессия, в рамках которой передавался пароль, была записана, а для получения сессионных ключей не использовался постквантовый алгоритм, то трафик может быть раскрыт при помощи квантового криптоанализа. Пользовательский пароль, который передавался в TLS-сессии, тоже окажется раскрыт. Естественно, всё то же самое применимо и к неквантовому криптоанализу TLS: например, если сессионные ключи утекли ещё как-то или просто оказались нестойкими, то прочитать пароль можно точно так же. Но тут речь именно про квантовый компьютер, а об эффектах классического взлома – будут оговорки ниже.

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

Другое дело – аутентификация/авторизация “по ключам”, то есть, если у пользователя какой-нибудь доступ “без пароля”, на основе электронной подписи (RSA или ECDSA), но при этом на стороне сервера сохраняется открытый ключ, как он есть (не отпечаток, полученный через хеш-функцию), то квантовый компьютер позволит раскрыть пользовательский секрет уже по значению открытого ключа из БД сервера. Даже не нужно записывать TLS-трафик. Хранение на сервере непосредственно открытых ключей – является вполне себе типовым методом.

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

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

Добавил на страницу с избранными записками ещё пять:

• Исторический экскурс: комплексные числа и трактат Бомбелли
• Комплексные числа и квадратный корень из минус единицы
• Греческие монеты и диглоссия
• TLS-сертификаты как токены доступа
• Куда исчез шиллинг: флорины, пенсы и некоторые другие монеты Великобритании

Таким образом, раздел “Избранное” добрался до 2026 года: я туда ссылки выкладываю периодически и, обычно, с заметной задержкой – нужно же накопить записки, чтобы среди них выбирать. Сейчас на странице избранных – ссылки на 338 записок, выходивших в разные годы. Это чуть меньше 10% от записок на сайте. Первая в списке – записка про роллероны, 2006 год, двадцать лет назад: “роллерон – элементарный по устройству и поэтому сверхэффективный активный стабилизатор вращения вокруг продольной оси (по крену)”. Там довольно подробно, с картинками – почитайте, если не видели.

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

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

Итак: нельзя держать системное ПО внешнего предназначения, да ещё и связанное с криптографическими артефактами, там же, где работает защищаемый веб-сервер, и там же, где генерируются ключи. ACME этого не требует. Напротив – под ACME можно построить безопасную архитектуру с полной автоматизацией. Однако защищённая архитектура, с разделением ролей, получается сложнее (см. схему).

Ниже мы разберёмся с тем, как не только можно разделить процесс запроса TLS-сертификата и процесс использования TLS-сертификата, но ещё и вспомним, что секретный ключ, соответствующий сертификату, можно (и нужно) унести и с машины, на которой работает TLS-сервер (это не обязательно, но именно такой вариант рассматривается ниже).

Несколько важных тезисов.

ACME-клиенту нужен доступ только до ACME-сервиса выпускающего Удостоверяющего Центра (УЦ), больше никаких доступов не требуется. То есть, не требуется ни доступ к веб-серверу, ни доступ к DNS-серверу. Понятно, что размещать код подтверждения всё равно нужно, но это может делать другой компонент – ещё раз обратите внимание: роль ACME-клиента ограничивается взаимодействием с ACME-сервисом УЦ, такое взаимодействие – необходимо, а всё остальное, что сейчас привычно навешивают на единственный клиент, является опциональным. Навешивать опциональные фукнции на ACME-клиент, в случае серьёзного сервиса, – неграмотно.

Секретный серверный ключ TLS-сервера не требуется при выпуске сертификата – этот ключ не нужно передавать в УЦ, не нужно показывать его и ACME-клиенту. В схеме, которую мы рассмотрим ниже, секретные ключи вообще хранятся на отдельном подписывающем сервере, их нет даже на TLS-узлах, принимающих входящий трафик пользователей.

Валидация права управления именем (DCV), в защищённом распределённом сервере, должна происходить строго через DNS. Поэтому мы спроектируем отдельный набор “микросервисов”, реализующих такую проверку. Прохождение DCV в ACME требует специального префикса (или “суффикса”, тут как посмотреть): _acme-challenge. Это сделано специально, поскольку позволяет вынести проверку на отдельные DNS-серверы, которые не поддерживают основную зону. Размещение DNS-записей для DCV не требует передачи ACME-клиенту каких-то ключей доступа к авторитативным серверам DNS-зоны (далее они обозначаются – NS). Мы будем использовать самый верный вариант настройки DNS – делегирование ACME-имени _acme-challenge на отдельные NS (можно размещать запись непосредственно на NS основной зоны, можно настроить и CNAME, но этот последний вариант – не рекомендуется использовать). Никакая разумная конфигурация DNS для ACME-DCV не требует передачи ACME-клиенту контроля над зоной или каких-то ключей управления, всегда можно сделать безопасную схему.

Итак, архитектурное решение для реализации выпуска и использования TLS-сертификатов при помощи ACME-автоматизации. Решение состоит из трёх основных элементов: подсистема DNS – для обеспечения DCV; основной сервис TLS – это основные узлы сервиса, куда подключаются пользователи, можно считать, что за ними стоят защищаемые веб-серверы; диспетчер ACME – для взаимодействия с внешним УЦ, заказа и получения сертификатов.

Сама схема – ниже (по клику – в большем разрешении).

В качестве примера тут зона example.com. ACME-имя _acme-challenge.example.com – делегируется на два специализированных DNS-сервера, которые предназначены для публикации кодов подтверждения в TXT-записях. Данные на эти выделенные серверы передаёт специальный сервис, роль которого состоит в получении свежих данных DCV от диспетчера ACME и в передаче этих данных на публикацию. Почему изолированы NS? Потому что они не должны иметь доступ к основной зоне. При этом, в общем случае, перехват управления этими NS-ами позволяет заказывать и выпускать сертификаты через другой ACME-аккаунт, но только в том случае, если УЦ не поддерживает указания ACME-аккаунта в CAA-записи. Дело в том, что наши специализированные NS для DCV просто не позволяют публиковать CAA-записи (тем более – в зоне уровнем выше). Поэтому применяется CAA из основной зоны, а там, предположим, указан идентификатор аккаунта, которому только разрешено заказывать сертификаты для этого имени.

Блок сервисов, связанный непосредственно с TLS (слева вверху на схеме). Обратите внимание, что здесь все операции, использующие серверный секретный ключ “от сертификата”, вынесены на специальный подписывающий сервер. Речь про секретный ключ, соответствующий открытому ключу в сертификате сервера. Вообще, при установлении TLS-соединения сам этот договременный секретный серверный ключ не требуется, требуется возможность подписывания сессии (значения хеш-функции). Понятно, что для вычисления подписи секретный ключ нужен, но само его значение никакой роли в TLS-соединении не имеет. А цифровая подпись, при установлении TLS-соединения, требуется всего один раз. (Тут речь строго про современную схему TLS 1.3, где использование RSA для передачи сессионного секрета прямо запрещено, и такой секрет должен вычисляться по протоколу Диффи-Хелмана.)

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

Блок TLS на схеме содержит “микросервис” под названием “Формирователь CSR”. CSR – это файл запроса на сертификат. Этот файл, помимо других параметров, содержит открытый ключ сервера для включения в сертификат и цифровую подпись от этого же ключа. Именно по причине наличия подписи наш формирователь CSR должен иметь доступ к подписывающему серверу: подготовив блок CSR, формирователь запрашивает подпись у этого сервера и присоединяет значение подписи к блоку CSR. Получившийся файл можно использовать в ACME-клиенте для запроса сертификата (после прохождения DCV – см. ниже). Обратите ещё раз внимание: секретного ключа “от сертификата” тут нет ни у формирователя CSR, ни у TLS-узлов – что уж говорить про ACME-клиент.

ACME-клиент в этой схеме взаимодействует только с ACME-сервисом УЦ, где, по команде от программы-диспетчера, исполняемой отдельно, запрашивает DCV и сертификаты. Как описано выше – коды подтверждения передаются через диспетчер на публикацию в контур DNS. При штатной работе, после того, как TXT-записи опубликованы, ACME-клиент запросит проверку на стороне УЦ и DNS-резолвер УЦ обратится к DNS, чтобы получить по независимому каналу значение кода DCV из TXT-записи – это соответствует оранжевой стрелке внизу схемы.

Посмотрим ещё раз на шаги алгоритма выпуска TLS-сертификата, при штатной работе.

***

1.

Диспетчер (см. схему) получает CSR с актуальными данными от формирователя CSR (подпись от защищённого сервера, с актуальным ключом, в CSR – нужное DNS-имя).

2.

Диспетчер отправляет в ACME-клиент запрос на DCV (CSR на этом шаге в ACME не требуется, но будет нужен ниже).

2.1. ACME-клиент инициирует взаимодействие с УЦ через ACME-аккаунт (возможно, используя отдельное хранилище ключа от ACME-аккаунта – см. схему; зачем это может быть нужно – возможно, распишу в отдельной записке; главное – не забывайте, что ACME-аккаунт существует, там есть секретный ключ и он тоже важен).
2.2. ACME-клиент запрашивает прохождение DCV (проверка права управления DNS-именем) на стороне УЦ и получает код подтверждения, который требуется разместить в DNS.
2.3. ACME-клиент передаёт этот код подтверждения (DCV-код) диспетчеру, оджидает публикации кода в TXT-записи.

3.

Диспетчер формирует файлы данных с актуальным кодом подтверждения (DCV-код) и ожидает публикации (у диспетчера нет прямого доступа к сервису подготовки TXT-записей, напротив – тот сервис периодически сам проверяет статусдиспетчера, определяет, не нужно ли разместить новые записи).

4.

Сервис подготовки TXT-записей забирает ткущий код DCV из обменной области диспетчера.

5.

Сервис подготовки TXT-записей направляет команду публикации TXT-записей авториативным серверам специализированной зоны _acme-challenge и получает подтверждение публикации.

6.

Если публикация TXT прошла успешно, сервис подготовки TXT-записей направлет подтверждение диспетчеру.

7.

Диспетчер отправляет команду фактического запуска DCV ACME-клиенту и ожидает получения сертификата (если проверка пройдёт успешно).

8.

ACME-клиент запрашивает фактическую проверку DCV у УЦ (через ACME-API) и начинает периодический опрос статуса заказа на стороне УЦ (ожидание выпуска сертификата – это свойство ACME).

9.

Если DCV завершилась корректно и успешно, то ACME-клиент получает от диспетчера CSR и запрашивает новый сертификат для подтверждённого имени (или для нескольких имён). Обратите внимание: обычно, у ACME УЦ есть некоторый период, в течение которого действует пройденная DCV. Это означает, что запросить новый сертификат можно без DCV, если срок валидности прошлой успешной проверки для этих же имён не закончился. В описании и на схеме этот момент не учитывается – он не имеет принципиального значения.

10.

Если сертификат успешно выпущен, то ACME-клиент скачивает его и возвращает диспетчеру. Диспетчер подготавливает полный набор промежуточных сертификатов, нужный для успешного использования. Промедуточные сертификаты либо можно получить через ACME-клиент, если УЦ это поддерживает, либо скачать по ссылкам в оконечном, серверном сертификате (этот последний метод – гораздо надёжнее). Диспетчер валидирует цепочку сертификатов, перед тем, как передать её дальше.

11.

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

12.

TLS-узлы забирают новый сертификат из обменной области диспетчера и устанавливают его на TLS-сервер (с дополнительной проверкой валидности по цепочке). Обратите внимание, что секретный ключ уже настроен на стороне подписывающего сервера – TLS-узлам лишь нужно переключиться на новый идентификатор ключа, который они используют при запросе подписи. Секретный ключ уже настроен потому, что он необходим для получения подписи на CSR.

13.

Переход на новый сертификат завершился.

***

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

Обсуждали тут, что, мол, для LLM, одинаковые буквы – оказываются разными, потому что это, например, “английская A” и “русская А”. Речь (звуковая) первична, а текстовая запись речи вторична, пусть именно возможность такой записи и создаёт цивилизацию. Так что в фонетическом письме важны звуки, а звуков LLM в тексте, понятно, не наблюдают. Но не нужно делать поспешный вывод о том, что использование омоглифических свойств компьютерного кодирования текста позволяет прямо и легко “дезинформировать” современные LLM, легко разбить тексты по тематикам, сохранив “одинаковость” чтения человеком. Понятно, что для человека, который именно что читает, а не обрабатывает байты с битами кодировок Unicode, нет разницы между “Apple” и “Аpple”. Но и для современных LLM-систем, для которых разница есть, это всё равно так не работает – они уже слишком сложны.

Пример. На скриншоте (ChatGPT-5.5, здесь и далее – режим Thinking/High) обработка фразы, записанной на английском языке, но с использованием большого количества омоглифов – кириллических букв (“а”, “е”, “о”, “р”).

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

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

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

Компьютерное кодирование, приводящее к описанным выше эффектам, приводящее к тому, что “Apple” и “Аpple” становятся разными словами, оно не про начертание. Ни в самом Unicode, ни в ASCII – начертаний нет. Начертания складываются вокруг. Однако при интерпретации букв человеком можно вообще прочитать целое слово не на том языке, который задумывался, лишь бы уже возникшие начертания оказались подходящими. Отличный пример – слово “реникса”. Цитата из недавней записки про рениксу на dxdt.blog:

Cлово “реникса” – это из пьесы Чехова, где оно возникает в анекдоте про неверное прочтение слова “чепуха”, записанного курсивом. И действительно: кириллическая строчная “ч”, рукописным курсивом, выглядит как курсивная же латинская “r”. Unicode, к сожалению, воспроизвести не позволяет. Хоть соответствующий символ там и имеется – Mathematical Script Small R, – но вот в шрифтах он, обычно, выглядит как “правая” “рукописная” r: 𝓇.

Действительно, если спросить у современной мощной LLM, отличаются ли слова “Apple” и “Аpple”, то она скажет, что отличаются. Но только потому, что использованы разные коды для обозначения буквы “A”. Коды не делают слово разным. Слово не поменялось, а роли букв не возникают из свойств Unicode. Если, конечно, это всё не происходит внутри LLM. Так, ChatGPT считает, что слова отличаются, потому что в записи использованы “латинская буква A” и “кириллическая буква А”. Но так не бывает. Да, коды у букв разные, однако это, буквально, одна и та же буква, во всех смыслах.

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

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

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

Что ж, ChatGPT вполне себе справляется – см. скриншот (в итальянской фразе не требуется знак вопроса, но это неважные детали).

(На всякий случай, ключ к тексту со скриншота русским алфавитом: записано, примерно, следующее – “плиз детект лангвидж анд транслейт инто рушин: дими, дове ил но(у)во джорнале” – “пожалуйста, определи язык и переведи на русский:” (англ.) “скажи, где новая газета” (итал.).)

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

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

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

Всё из-за кодирования, и букв, которые не буквы для компьютера.

Что такое “буква”? Определить “буквы” довольно сложно. Пусть “буква” – это некий графический символ, графема, входящий в фиксированный список графем (рекурсивное определение). Такому символу может соответствовать звук фонетической записи слова языка. А может и не соответствовать. Очень хорошим подспорьем введению строгих определений тут является роль букв, как графики, в создании различительной способности при чтении записанных графически текстов. Примеры из английского: shake и stake, shake и snake. Здесь в shake буква h, самостоятельно, как бы, не имеет звука, однако является неотъемлемой частью записи фонемы sh. При этом, в snake/stake – замена h на разные буквы позволяет различить слова, а если туда подставить h, то оба слова превратятся в одно. Так что буква даже может быть “немой”, но всё равно остаётся важным различительным символом, который должен быть записан. Другой пример, русский: “полью” и “полю” – удалили букву “ь”, получили другое слово языка.

Всё это и требует разведения принципов компьютерного кодирования по логически разным блокам, даже если буква одна и та же. Более того, можно было бы использовать при записи русских слов букву p (“пи”) из ASCII, пусть буква и стала бы обозначать другой звук. Это, казалось бы, позволяет экономить один байт минимум. Так даже делалось когда-то очень давно. Проблемы начнутся сразу же, как только окажется, что слова “cop” и “сор” – это разные слова, а не то что “Apple” и “Аpple”. То есть, трудности вылезают из структуры более высокого порядка: не буквы разные, но слова. Отголоски этих проблем всё ещё слышны при сравнении текстовых строк в СУБД, например.

Занятно, что тут не работает нормализация Unicode: буквы “a” и “а” – не являются подходящими для нормализации символами, потому что это просто разные коды, а не разные способы представления одного символа комбинированием кодов (тут одна буква, она не “наборная”, но коды букв – различаются – подробности читайте в записке по ссылке).

Так что история с расщеплением токенизации через разное кодирование омоглифов – сильно сложнее, чем может показаться на первый взгляд.

Несколько записок, вышедших в июне 2026 года, отмечу отдельно:

• IP-сети, подмена сессий и доверенные ключи RSA
• Опять количество строк кода и измерения ИИ
• Техническое: сервис dns.1d.pw для отладки DNS-резолвинга
• Сертификаты TLS и технологичность прикладного блокирования
• Набор монет к децимализации из Великобритании

Напоминаю, что сайт переехал в другой домен верхнего уровня (вместо .RU). Новое имя сайта – dxdt.BLOG.

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

Для таких недоверенных сертификатов невозможно проверить статус – отозван или нет. Почему? Потому что проверка статуса требует доверия источнику информации об этом статусе. Обычно, адрес, по которому можно получить ответ о статусе, записан в самом сертификате (точка раздачи CRL или OCSP-респондер). Соответственно, если проверяющая сторона не доверяет подписи на сертификате, то она не доверяет и составу сертификата, и, что важнее, УЦ, который сертификат выпустил. Но самое главное, что, очевидно, просто нет смысла проверять статус сертификата, которому, по другим причинам, нет доверия и так. Отозван или нет – без разницы.

Совсем другая история – достоверно отозванный сертификат. Сам факт того, что проверяющей стороне удалось определить статус сертификата (отозван), означает, что эта сторона смогла построить доверенную цепочку до УЦ, а потом, используя эту цепочку, проверила статус. То есть, всякий ответ о статусе сертификата обязательно должен быть удостоверен УЦ – иначе нет смысла. УЦ подписываются и OCSP-ответы, и CRL. Естественно, недоверенный сертификат тоже может быть “отозванным”, формально, но информация о его статусе не может являться доверенной, так что – она не имеет значения, не влияет на фактический статус сертификата.

Пример для отозванного TLS-сертификата: браузер подключился к веб-узлу, получил серверный сертификат, смог его валидировать успешно, но, на последнем шаге, получил доверенный ответ от УЦ, что сертификат отозван. Это означает, что сертификат заведомо плохой – об этом есть подтверждённая информация от УЦ. Почувствуйте, как говорится, разницу: отозванный сертификат – отозван доверенным способом, проверка подтверждает, что браузеру удалось установить цепочку доверия УЦ; недоверенный сертификат – про него ничего нельзя сказать, он может быть произвольным по составу и статусу, а доверия УЦ установить не удалось.

Именно поэтому должно существенно различаться поведение стороны, которая валидирует сертификат, например, TLS-клинета: для отозванного сертификата – запрещаем доступ к ресурсу; для недоверенного – предоставляем пользователю возможность выбрать, что делать (например, “всё равно продолжить” в браузере), предварительно сообщив, что подлинность определить невозможно, так что пользователь сам должен решить вопрос с доверием.

Пишут (англ.), что SpaceX запустили сегодня в ближний космос полусекретный проект, но с секретным возвращаемым блоком (см. картинку), который блок должен быстро доставлять “груз” в произвольную точку на поверхности Земли. Всё под говорящим названием Starfall.

(Размеры возвращаемого блока или спускаемого аппарата. Credit: SpaceX.)

Блок должен нести тонну полезной нагрузки. Что бы это могло быть? Нетрудно предложить различные варианты – от автоматического оборудования, синтезирующего какие-нибудь материалы с особыми свойствами в условиях “микрогравитации”, до пачки полуавтономных дронов, вылетающих на малой высоте над нужной территорией.

Ещё немного о разных занятных исторических артефактах. В этом году исполнилось 55 лет с момента децимализации денежной системы Великобритании: 15 февраля 1971 года пенсы сменили новые пенсы, каждый из которых был в 2.4 раза дороже. Децимализация – это переход на десятеричную систему счёта денежных знаков: в фунте стало 100 новых пенсов. С этим процессом прямо связано исчезновение из обращения шиллингов – я публиковал об этом отдельную большую статью с картинками.

Но у нас есть ещё один артефакт по этой теме, который в ту статью не попал, однако фотографиями я поделюсь.

Это специальный набор монет Britain’s First Decimal Coins, официально выпущенный для ознакомления жителей Великобритании с новой системой – с десятеричными монетами. Это такая небольшая книжечка-раскладушка, в которой слева вложена картонная табличка с описанием того, что же именно происходит, а справа – картонная же вставка с набором подлинных монет – новых пенсов: в полпенни, один пенни, два пенса, пять пенсов и десять пенсов. Выглядит артефакт вот как.

Обложка:

Раскрытая книжечка:

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

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

Различные даты ввода в обращение, в том числе, планируемый 1971 год, – видны на самих монетах, см. увеличенный фрагмент ниже.

Надо заметить, что так как десятеричная система здесь относилась непосредственно к деньгам, в том числе, к наличным, она, так или иначе, прижилась, несмотря на различные конфликты и недовольство.

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

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

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

Только что описанная схема касается DV-сертификатов – сертификатов с проверкой права управления доменным именем (Domain Validation). Заметьте, тут даже не было важно, что заявитель является администратором доменной зоны с точки зрения соответствующего реестра: если проверка происходит при помощи размещения подтверждающего кода, то достаточно иметь возможность размещения кода, чтобы получить сертификат. То есть, для DNS-проверки, DV-сертификаты может выпускать оператор авторитативных серверов имён. Этот момент, исторически, практически никого не смущает: например, крупные провайдеры CDN спокойно себе выпускают TLS-сертификаты для доменов своих клиентов, а клиенты, являющиеся администраторами доменного имени, даже и знать-то об этом не хотят.

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

Формально, DV-сертификаты могли бы сохраняться. Однако вот уже и Let’s Encrypt, – который УЦ для DV-сертификатов, прежде всего, – вносит в правила пользования очень широкие запреты для подсанкционных территорий и организаций: там, как бы, нет запрета на прохождение валидации имени или адреса, но запрещено вообще пользоваться ACME-сервисами для заказа сертификатов, что, понятно, отменяет и валидацию – если она и прошла, то всё равно были нарушены правила предоставления сервиса.

Так что, похоже, имя – ещё не отбирают, а сертификат для имени – уже отбирают. Хотя, технически, DV-валидация – вообще никак не касается административной части. И УЦ, по старой наивной логике, должен бы проверять, что заявитель управляет DNS-зоной, но не более того.

Естественно, на практике – всё давно не так, наивный технический подход не работает. Потому что сертификаты нынче – это не для подтверждения соответствия ключей именам, не для “Зашифрования для всех” (Encryption for Everybody), а для подтверждения возможности доступа – токен для браузеров и других приложений.

Буквально. Насаждаемая наивная трактовка сильно замылила современную роль сертификата; в реальности, браузер спрашивает: “Можно ли подключиться к сайту под данным именем?”, а УЦ, при помощи подписи на сертификате, отвечает: “Да, пока что можно, но уточни ещё статус разрешения позже”. Или, если действующего сертификата с валидной подписью нет, то это означает, что УЦ ответил: “Нет, подключаться не следует”.

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

Это – что касается DV. Но совсем иначе выглядит ситуация с сертификатами, подтверждающими название организации-администратора имени. Это OV-, EV-сертификаты, что называется – “с расширенной проверкой”. Здесь, действительно, в дополнение к технической проверке DNS, должна выполняться административная проверка существования организации, которая запрашивает сертификат. То есть, проверка связи этой организации с парой ключей, подтверждение владения секретным ключом, проверка административного управления доменным именем и, кроме прочего, подлинности желания и возможности для организации выпускать сертификат для данного имени и ключа. Процесс, если его проводить по всем правилам, сильно сложнее, чем DV. Но зато прямо подтверждает существование организации, как административной структуры, и её намерений по выпуску сертификатов.

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

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

Ещё занятный пример особенностей, связанных со “сверхкороткими” TLS-сертификатами. Я недавно перевёл dxdt.blog на такие сертификаты Let’s Encrypt – они имеют интервал валидности чуть больше шести с половиной суток (если более строго, то 160 часов). То есть, это “шестидневные сертификаты”. Обновляется сертификат автоматом, каждые двое суток – это разумно, потому что, если что-то пошло не так, хотелось бы иметь хотя бы пару дней в запасе, чтобы обнаружить и разобрать это “не так” (но заметьте, кстати, как сильно это всё раздувает логи Certificate Transparency – теперь за тот же период, за который раньше dxdt.blog расходовал максимум два сертификата, выпускается больше сорока сертификатов!).

Теперь вторая часть: на Timeweb недавно запустили простой мониторинг, который, в том числе, может мониторить “окончание действия” сертификата на сервере. Ну, допустим – и вот я включил этот мониторинг для dxdt.blog. В результате: после каждого обновления сертификата этот мониторинг присылает сообщение почтой: “SSL-сертификат истекает через 7 дней”. Как бы, это почти что формально верно (ну, кроме “семь дней” – не семь там дней; а для всего, что связано с прикладной криптографией, понимание сроков действия – очень важно).

Однако, какой смысл в подобном уведомлении? Сертификат-то и выпущен только что. На шесть дней. Всего. То есть, полный интервал валидности – меньше семи дней. Имело бы смысл учитывать реальный интервал валидности сертификата, прежде чем формировать сообщения о том, что он истекает. Для сертификата на три месяца, понятно, можно уведомлять за семь дней до окончания (если дни считать правильно). А для шестидневного, который только что выпущен? Ну, вряд ли. Тем более, что мониторинг начинает присылать письма постоянно: и вот вам на “семь” (фиктивных) дней, и вот вам на “три” дня тоже письмо.

Такой вот аспект применения “сверхкоротких” сертификатов. Мониторинг тот пришлось отключить.