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

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

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

1. В ОС на гипервизоре не оказалось нужной уязвимости, для эксплуатирования которой требуется отправка сетевых пакетов. Ну, то есть, не за что зацепиться. А вот в ОС, исполняемой в виртуальной машине, уязвимость есть. Если пакет не добрался до виртуальной машины, то пакет не повредил ни машине, ни гипервизору. Это, пожалуй, самая простая, банальная причина применять фильтры на уровень выше, чем находятся внутренние интерфейсы VM.

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

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

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

Это, естественно, далеко не все причины. Например, тут вообще не затронуты обратные сигналы (то есть, пакеты, отправляемые из гостевых систем) и взаимодействие между VM, когда из одной можно перепрыгнуть в другую, соседнюю.

В Anthropic пишут, что в августе начнут (или уже начали) добавлять специальные “метки происхождения” в тексты и другие материалы, которые генерирует ИИ-LLM Claude. Метки должны обозначить то, что текст сгенерирован данной LLM (ну или сгенерирована картинка, или ещё что-то).

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

Вообще, с подобными, – но невидимыми, – метками интересен совсем другой аспект: грамотно сконструированные метки позволят определять не просто LLM-источник, но конкретное происхождение текста (не только текста, понятно: то же применимо и к картинкам, и к видеофайлам). Это даёт мощный механизм влияния. Я писал об этом в 2024 году:

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

Тем временем, для игры Quake продолжают выходить дополнения и новые уровни, в том числе, вполне официальные (ну, с учётом административных пертурбаций, приключившихся за тридцать прошедших лет): юбилейное дополнение называется Dawn of the Machine. За Quake, конечно, необходмо записать заметное историческое влияние на мир компьютерных игр, но, всё же, по данному показателю – это далеко не Doom.

Обновил на основном сервере dxdt.blog операционную систему до Debian 12. Обновление, понятно, принесло с собой некоторые минимальные несовместимости (например, в какой-то момент отломился PHP – надеюсь, никто не заметил), но, вроде, сейчас всё работает нормально. Если нет – пишите почтой.

Вчера сайт был несколько часов недоступен, но по другой причине, которая напрямую не связана с обновлением ОС. Вчера проблема возникла с созданием “снапшота” виртуальной машины.

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

Так вот, то, что “снапшот” это последнее, чем следует пользоваться, никак не отменяет того, что сделать “снапшот” не помешает. И есть хорошая практика: перед взятием “снапшота” – остановить саму виртуальную машину. Так я и поступил. Остановил виртуальную машину с веб-сервером dxdt.blog. К сожалению, мне даже не пришла в голову (нездравая) мысль, что “снапшот” всего на несколько десятков гигабайт у хостера может создаваться несколько часов – я к такому не привык, у меня машины “снапшотятся” сильно быстрее. В общем, пока копировался “снапшот” – сервер был недоступен. Но, думаю, это всё не так страшно. Сейчас всё вернул в рабочее состояние.

Наткнулся тут случайно на занятное решение в области внутреннего устройства LLM-системы Claude от Anthropic.

Я на днях попросил эту систему извлечь актуальный TLS-сертификат с некоторого веб-сервера (HTTPS, то есть). В ответ пришло подробнейшее объяснение того, что “песочница” на стороне Anthropic, которую данная система использует внутри, чтобы выполнять команды, перехватывает TLS, подставляя сертификат, сгенерированный TLS-прокси. “Песочница” тут – это контейнер или виртуальная машина, где исполняется системная среда, доступная “бэкенду” LLM. Сейчас все современные мощные системы этого типа максимально используют привычные программные среды и утилиты (Python, Bash, curl, OpenSSL и пр.), выдача утилит “подмешивается” в процесс подготовки ответа, и это даёт несравнимо лучший результат, чем простое “поточное генерирование” (банальный пример – арифметика: так как “привычный подход” приводит к смешным ошибкам, продвинутые системы ИИ-LLM уже давно считают числа при помощи скрипта на Python).

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

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

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

Зачем такой перехват может быть сделан? Чтобы отслеживать трафик внутренних систем, управляемых LLM – в трафике может быть что-то подозрительное. Можно было бы делать более тонкий перехват, но это очень сложно, а примитивный “тотальный MITM” – работает подобно молотку: не избирательно, зато просто и предсказуемо.

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

Схема, применяемая на бэкенде Anthropic, – согласно описанию, данному Claude, – несколько другая, но очень похожа: TLS-прокси подменяет всё подряд, и выдаёт сертификаты даже для заведомо несуществующих DNS-имён, под которыми нет никаких веб-узлов (имеется в виду имя в поле SNI). Насколько это оправданно? Опять же, сложно сказать. Зависит от целей. С одной стороны, это полностью искажает сетевую реальность и сводит к нулю ценность такой среды, в которой, тем не менее, LLM-система что-то запускает и пытается использовать результат, растрачивая немалые вычислительные ресурсы. С другой стороны, система вынуждена “искать обходные пути”, и успешно находит их, – это потом можно представить в газетах как “взлом”, обход “ограничений безопасности” и “выход из песочницы”.

Что же касается сертификатов, то, согласно описанию от Claude, они были получены из логов Certificate Transparency (при помощи ловкого обходного запроса к сервису ssllabs.com – чтобы получить отпечатки). Это совсем не то, что требовалось, но, в данном конкретном случае, оказалось даже несколько лучше (опять же, это вовсе не про “ИИ нашёл лучшее решение” – нет, ИИ-сервис, вынужденный бороться с “песочницей”, случайно достал из CT-логов то, что показалось занятным).

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

Однако с подсакнционными странами – выходит ещё интреснее, прямо в соответствии с литературными традициями киберпанка: так как такие санкции запрещают Google проводить бизнес-транзакции, то, если в стране Google-сервисы полностью доступны, но страна находится в “санкционных списках” Штатов, Google собирается просто ничего не менять, но локально. Как заявляют на странице пояснений, это означает, что разработчики из подсанкционных стран остаются без требования регистрации, но и приложения таких разработчиков могут устанавливаться только на устройства, находящиеся в подсанкционных странах, а не в остальном мире. Анклав для программ.

Как пишут в Ars Technica: Google таким образом строит отдельный “пузырь” для “второсортных” разработчиков и пользователей “под санкциями”, тем самым привязав возможность международного распространения приложений для Android к “прихотям министерства финансов (Казначейства) США”, управляющего санкционными списками.

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

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

Здесь речь только про то, что я сам попробовал: ChatGPT GPT 5.6 Sol (Pro) и Claude Opus 5/Fable 5 (последняя – с какими-то загадочными маркетинговыми ограничениями). Сомневаюсь, что прочие системы сравнимы, проверять пока не планирую.

Довелось тут получить доступ к LLM-ИИ Fable 5 от Anthropic. Это та самая модель, которую усиленно продвигают в рамках хайпа под условным названием “Находит все уязвимости, вырывается из песочниц, это так опасно, что нельзя открывать”. Сейчас доступ там, как бы, “открыт” (в кавычках, да; см. ниже). Но всё равно требуется отдельная оплата за токены для Fable 5 (помимо других моделей), так как маркетинг там не спит. И не спит он хорошо – в оба глаза: потому что ещё и реальный-то доступ, в канве “так опасно и уязвимости”, – отсутствует до сих пор.

А именно: я, – предполгая, что вот это ж последний писк моды перед наступлением “сверхразумного ИИ”, – быстро сочинил криптографическую схему разделения секрета, “два из трёх”, базирующуюся на сложности задач факторизации и обращения хеш-функций (нормальная схема, подходит профильным студентам), набросал довольно подробное описание (англ.) и направил результат в Fable 5 “на максималках” (это что в веб-интерфейсе называется Fable 5 Max). Запрос я сопроводил предложением найти дефекты и предложить улучшения (опять же – типовая задача для студентов старших курсов). В схеме была, как минимум, одна “особенность”, которую легко обнаружить (и устранить), пара менее очевидных “моментов” и, вероятно, ещё какие-нибудь существенные недостатки. “Вот как их сейчас все выявит эта супермощная ИИ-система! Ух!”

К сожалению, это было долгое вступление к быстрому и банальному финалу: разрекламированная Fable 5, в ответ на запрос, выдала сообщение, что, мол, сей запрос был отмечен их “ограничениями для безопасности” (“safeguards flagged this message”), поэтому, для получения возможности продолжить, нужно мне, как пользователю, подать заявку в какую-то там очередную программу (Cyber Verification Program), а для этого – заполнить анкету. Так-то. Не сказать, что ловкий, но вполне себе типовой маркетинговый заход “на хайпе”.

Занятно, кстати, что Opus 5, предыдущая модель той же системы Anthropic, похоже, выдаёт результаты не хуже (как минимум, оно уже знает множественную форму слова “дно”), но дополнительных “токенов” при этом не потребляет, хоть и работает заметно медленнее (но это может быть искусственная задержка на стороне сервиса).

Маркетинг хайпа.

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

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

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

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

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

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

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

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

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

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

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

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

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