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

Обсуждали тут, что, мол, для 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 дней”. Как бы, это почти что формально верно (ну, кроме “семь дней” – не семь там дней; а для всего, что связано с прикладной криптографией, понимание сроков действия – очень важно).

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

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

Кстати, а вот попалась мне монета в один бермудский доллар, в форме треугольника Рёло – фигуры с постоянной шириной: получается Бермудский треугольник Рёло.
На аверсе – портрет королевы Елизаветы II:

На реверсе – крушение корабля Sea Venture (как раз в Бермудском треугольнике):

(Фоном тут служит купюра в сто советских рублей, не обращайте внимания – к доллару с королевой купюра отношения не имеет.)

Перевёл, в соответствии с современными тенденциями, dxdt.blog на “короткие” TLS-сертификаты Let’s Encrypt, со сроком действия шесть дней (плюс-минус). Но секретный ключ пока оставил специально подобранный. Посмотрим, как оно будет работать.

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

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

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

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

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

Этот уровень приложений, как ни странно, очень технологичен. Но речь тут вовсе не про “используй фреймворк “Имярек”, чтобы лучше адаптировать агентов типа John Doe”. Нет. “Фреймворк и агенты” – это технологии, но не технологичность. Технологичность скрывается за процессом контроля над способом применения технологий. Если на примере инфраструктуры УЦ: сейчас кругом только и слышно, что про ACME и его использование – это про протокол автоматического заказа и получения TLS-сертификатов. Но реально ли речь всегда идёт о протоколе? Оказывается, нет. ACME – весьма заумный и развесистый протокол. Мало кто читал спецификацию, мало кто его понимает. Оказывается, что в большинстве случаев использовать хотят не протокол, а некий готовый продукт, популярную утилиту или библиотеку на основе ACME. Например, хотят не ACME, а чтобы работали certbot или acme.sh, а также и какой-нибудь ещё фреймворк. Вот эта зависимость – и есть технологичность, а не просто технологии.

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

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

Использование хеш-деревьев в TLS-инфраструктуре веба, в TLS-сертификатах, обусловлено переходом на постквантовые криптосистемы цифровой подписи. Тоже хороший пример. Возможно, что в некоторый момент ведущие разработчики браузеров скажут, что браузеры больше не считают стойкими и надёжными сертификаты, выпущенные без постквантовой криптосистемы, а соответствующие веб-сайты – будут отображаться “как небезопасные”. Сложно ли такое представить? Конечно нет. Это вполне логично – устаревшие технологии в какой-то момент оказываются слабыми, браузер должен их блокировать тоже – какие могут быть возражения? Такое уже несколько раз происходило, и с DSA, и с SHA-1, и с длительностью действия сертификатов, и так далее, и тому подобное.

Ещё раз подчеркну – хитрость в том, что, действительно, устаревшие криптосистемы теряют стойкость, это без всякого сарказма. А вот уже с длительностью действия сертификатов – есть разные точки зрения, как говорится. Но Google в браузере Chrome даже не собирается поддерживать постквантовые криптосистемы подписи сертификатов, кроме как в варианте с хеш-деревьями (MT-сертификаты). Так что токены доступа – станут токенами доступа, и эта роль не зависит от типа носителя.

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

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

В продолжение предыдущей записки, про dns.1d.pw. Вот как серверы данной зоны видны со стороны сервиса проверки – есть DNS over TLS на всех узлах: