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

Кстати, в продолжение записки про геметрическую алгебру Евклида и разность квадратов – воскресное чтение манускриптов (давно не было). Как известно, основная часть трудов Евклида дошла до нас лишь в средневековых “копиях копий”. То есть, на манускриптах. Один из важнейших таких манускриптов – Vat.gr.190 из Ватиканской апостольской библиотеки, датируемый девятым веком нашей эры и содержащий тексты “Элементов” (“Начал”). Фрагмент с записью формулировки Предложения 5 из второй книги на древнегреческом приведён на скриншоте ниже.

За исключением комментариев на полях и между строк (схолии), это как раз тот текст, который упоминается в исходной записке (плюс пара строк начала доказательства; сама формулировка заканчивается словом τετραγώνῳ во второй строке снизу на скриншоте, а схолии легко распознать, – не не прочитать, – благодаря другим чернилам и почерку).

А вот чертёж из манускрипта, соответствующий этому Предложению, почему-то подкачал – см. следующий скриншот.

Здесь и точка Γ не делит прямую линию на равные части, и Δ прижата не к той границе. Казалось бы, для геометрии это не так уж важно, смысл не меняется, но всё же.

Сейчас почти весь TLS-трафик в вебе, защищённый криптосистемами с постквантовой стойкостью, использует для согласования симметричных ключей гибридную криптосистему X25519MLKEM (X25519+ML-KEM). Что здесь означает термин “гибридная”? А означает он, что объединяются секреты, полученные в результате работы двух криптосистем: ML-KEM и X25519. Возможны сочетания ML-KEM с привычными вариантами ECDH – логика их устройства такая же, как и в случае X25519, поэтому дальше, в качестве примера, используется только X25519.

Итак, X25519MLKEM это не какая-то особенная криптосистема, в которой “объединяются X25519 и ML-KEM”, а всего лишь указание на параллельное использование пары криптосистем, где объединяются не криптосистемы, а их вывод – общие секреты сторон. Причём, даже это объединение выполняется самым простым способом: байты, выведенные ML-KEM, дописываются к байтам, выведенным X25519. Желаемую постквантовую стойкость обеспечивает часть ML-KEM. Минимальное практическая взаимосвязь реализаций двух криптосистем тут возможна разве что на уровне генератора (псевдо)случайных чисел и хеш-фунций (но при этом ML-KEM использует SHA-3/SHAKE256).

Таким образом, в сильно гипотетическом случае появления квантового компьютера, пригодного для криптоанализа, стойкость подобных гибридных ключей всего лишь упадёт в два раза, если считать по битовой разрядности: квантово-компьютерный атакующий сможет вычислить секрет X25519.

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

Зачем же тогда нужен гибрид? Базовая причина довольно простая: подстраховать ML-KEM на тот случай, если данная криптосистема окажется очень уязвимой для классических атак. Проще говоря, сломают именно алгоритм ML-KEM. Вообще, идея внедрения постквантовой криптографии довольно старая (это может показаться контринтуитивным, но криптосистемы с постквантовой стойкостью появились даже раньше, чем был предложен квантовый алгоритм Шора для взлома других криптосистем). Эксперименты с практическим внедрением новых криптосистем в TLS тоже проводились раньше, до появления стандарта на ту же криптосистему ML-KEM.

Например, в 2019 году Cloudflare совместно с Google Chrome испытывали сочетание SIKE и X25519 (эксперимент CECPQ2b), где постквантовую стойкость относили на счёт криптосистемы SIKE. Однако использованная версия SIKE оказалась недостаточно стойкой к классическим атакам. Так что, не будь в составе того эксперимента X25519, которая пока сохраняет свою стойкость, все TLS-сессии, установленные в рамках эксперимента с SIKE, были бы сейчас скомпрометированы постфактум (если, конечно, их кто-то записал). Квантовый компьютер для этого не потребовался бы. Такая же ситуация возможна и для ML-KEM (пусть ML-KEM и использует другой, относительно SIKE, математический аппарат).

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

Конечно, именно поэтому никто не может гарантировать, что завтра не будет полностью взломана и X25519 – классическая часть гибрида с ML-KEM. Но, всё же, ML-KEM и более новая, и использует другой математический аппарат. А X25519 уже успешно и массово работает десятилетиями, а эффективных атак пока выявлено не было. Как бы там ни было, но один факт не вызывает сомнений: две независимых криптосистемы, – обычно, – лучше, чем одна.

Кроме теоретических аспектов, важны и практические: для той же ML-KEM требуется новая реализация, в которой много других алгоритмов, по сравнению с X25519 (или каким-то ещё вариантом ECDH). Новая реализация – это всегда новые дефекты и уязвимости именно в реализации, без учёта самого математического алгоритма. То есть, если использовать только ML-KEM – практически гарантированы новые критические ошибки, которых уже нет во второй части гибрида – в X25519. Более того, части ошибок реализации в X25519 просто и не может быть, потому что там другая математика.

Считается, что ML-KEM защищает от криптоанализа на гипотетическом квантовом компьютере. Очевидно, если бы подходящий квантовый компьютер появился, то использование гибридной пары с X25519 тут же потеряло бы смысл, так как эта криптосистема оказалась бы взломана. Чем не обоснование для отказа от гибрида? Но ведь этого квантового компьютера ещё нет и на горизонте! Так что обосновывать этим гипотетическим событием отказ от гибридных криптосистем на практике – несколько странно. Особенно, если учитывать, что никто не отменял классических атак на ML-KEM, и они пока что выглядят куда более реальными, чем квантовый компьютер для криптоанализа.

И тем не менее: стандарты – не требуют гибридов, а в IETF уже есть черновики RFC, описывающие “чистое” использование той же ML-KEM в TLS 1.3.

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

“Если прямую линию разделить на равные и неравные [отрезки], тогда прямоугольник, сформированный равной и неравной сторонами, плюс квадрат на стороне между [ними], равны квадрату на половине”.

“На половине” – тут имеется в виду квадрат на “равной” части исходного отрезка. Рисунок дан ниже – из него должно быть понятно.

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

Что именно здесь записано у Евклида? Разделим линию AB точкой C на равные части (половины: AC == CB), и точкой D на неравные (D, например, лежит на отрезке CB, см. рис.). Тогда утверждается, что AD*DB + CD*CD = CB*CB.

Воспользуемся современными алгоритмами и перепишем выражение: CD*CD – CB*CB == AD*DB. Дальше (см. рис.), по построению: AD == CB + CD; DB == CB – CD; следовательно, CD^2 – CB^2 == (CB+CD)*(CB-CD).

То есть, это геометрический вариант известного алгебраического соотношения – разности квадратов. Аналогичные параллели есть и у всех прочих Предложений второй книги “Элементов”.

Нередко можно услышать, что перспективные ИИ/LLM не заменят настоящих разработчиков и специалистов потому, что LLM нередко генерирует “решения” с грубыми ошибками, а чтобы понять, где эта ошибка, в чём она состоит и как её исправить – нужен тот, кто реально понимает, что же происходит. То есть, после наступления “эпохи развитого ИИ”, востребованными останутся специалисты с большим опытом и глубоким пониманием темы. Эти специалисты ещё и будут крайне редки, так как везде уже ИИ с LLM оказал влияние. Казалось бы, если результаты генерирования ИИ зашли в тупик, то такой специалист только и может выручить.

Логично.

Вот только тут неявно предполагается, что цель – получение полезного продукта, а не тупика. Это существенное допущение. Оно работает лишь до тех пор, пока достигнутый “тупик” просто не объявляется тем же ИИ единственным возможным результатом. И вот – “скрипач” оказывается не нужен.

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

Представьте, что именно LLM используется для определения того, можно ли реализовать решение некоторой задачи, можно ли исправить ошибки в каком‑то коде. Зачем? Чтобы повысить качество процесса, уменьшить количество итераций. Скармливание вывода одной LLM в другую LLM – типовой подход уже сейчас. Так что использование LLM на втором слое обработки задач не выглядит удивительным достижением. Например, несколько сомнительная, но очень популярная, идея, что обнаруживать тексты, сгенерированные LLM, нужно при помощи другой LLM, обученной на текстах первой, регулярно получает практические воплощения. Да и ИИ‑исследователи (“автоматические учёные”, как researcher) уже то и дело предлагаются через СМИ.

При написании студенческой, научной работы – использование LLM не только больше не является чем‑то “из ряда вон”, но уже иногда и прямо поощряется. Несомненно, тут есть куча оговорок: необходимо понимать, что хорошая LLM – это полезный инструмент обработки текста. Проблема в том, что появились новые трактовки понятия о полезности. Например, объявляется полезным для процесса обучения “исправление текста за ИИ/LLM”.

Действительно, в самом по себе использовании калькулятора на уроках математики ничего плохого нет, однако проблемы начнутся тогда, когда на смену изучению арифметики придёт “знакомство с назначением кнопок калькулятора”, чтобы “научиться правильно формулировать ему задания”. В такой парадигме нет места кому‑то, кто будет изменять результаты LLM не в учебных целях, да не получив одобрения другой LLM. Когда доступ к подобному ИИ имеется в изобилии, то ИИ/LLM и может объявить, что задача не решается в принципе, так что нет смысла звать “древнего инженера”.

Предположим, LLM “спроектировала” подъёмный кран, который всегда переламывается. Промпт переписывали по инструкции разными способами, но нет, не выходит прочный подъёмный кран. А более мощная LLM пишет, что сконструировать подъёмный кран, который не переламывается, невозможно в принципе. С развернутым обоснованием. Можно ли в принципе подобрать такие требования для крана, что построить соответствующий механизм невозможно? Можно, конечно. Хорошо. Достаточно теперь обобщить это наблюдение при помощи LLM.

Да, проблема с генерированием надёжного результата скорее решится тем, что и подготовка выводов о невозможности достижения результата тоже переходит к ИИ/LLM. Что ж, если посмотреть на современный хайп, то для этого всё и затевается, верно? “Сверхразумный ИИ” решает любые задачи, исследует все возможные исследования одновременно, и не может ошибаться, а поэтому всегда поможет.

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

Сверхразумный ИИ обещают уже чуть ли не в этом году. Ну или в 2030, что тоже не так далеко, как хотелось бы. Выглядит сомнительно. Если только не считать, что степень сверхразумности будет определяться по сообщениям газет: может же так быть, что какую‑то новую систему просто объявят сверхразумной? Вполне. Посмотрите на эту социальную область повнимательнее: тема активно развивается десятки лет, но требований для расстановки статусов ИИ так и не появилось. Есть, впрочем, регулярно обновляемый список “сомнений”, которые подстраиваются под каждый новый уровень. Например: появились системы, распознающие буквы на картинках, – нет, это далеко не ИИ; появились чат‑боты, генерирующие связный текст на естественном языке, – ну, это уже ближе, но всё равно нет, ещё не ИИ; и так далее. Только подтверждает существование самой возможности “сверхразумности” через объявление: всегда можно возразить, что некоторые много лет подстраивают уровень своих сомнений, поэтому и тут, традиционно, сомневаются.

Вернёмся к подъёмному крану: пусть разработка крана зашла в тупик, но ведь у ИИ нетрудно узнать непосредственно, как ещё можно поднимать грузы на высоту, верно? “Делайте грузы круглыми и закатывайте их по рельсам при помощи велосипеда, снабжённого системой блоков” — сообщает, предположим, ИИ. Так что тут точно нет места для дополнительного обращения к какому‑то “уникальному специалисту”: ИИ отверг одно направление, “научно” объяснил, что оно “невозможно”, и предложил другое, с круглыми грузами. Точка.

В такой конфигурации Нового средневековья некоторые технологические направления начнут быстро “засыхать”, а другие – требовать для поддержки всё больше механических ресурсов, но не специалистов. Сверхидея исходной концепции про редких незаменимых специалистов – в сохранении понимания технологий. Сохранение понимания – не равно сохранению только технологии. Человеку, чтобы хорошо понимать ту или иную технологию, нужно постоянно и непосредственно взаимодействовать с объектами, определяющими свойства данной технологии, а не просто выполнять ритуалы. Ритуалы при этом важны, сомнений нет. Но кто сказал, что концепция сохранения технологий не будет заменена на сохранение даже не самих ритуалов, а представлений о ритуалах? Такой вариант вполне вероятен. ИИ, как говорится, в помощь. (Да, тут сразу вспоминаются Adeptus Mechanicus из одной весьма известной игровой вселенной.)

Если технологии начнут “засыхать”, то кто же будет обслуживать дата‑центры с миллионами микропроцессоров, подливая волшебное масло в систему охлаждения? Кто угодно, с нужным уровнем допуска. По инструкциям, выдаваемым LLM, которые на тех микропроцессорах работают. Да, в какой‑то момент система охлаждения сломается. Но далеко не сразу, это же путь медленного угасания.

И всё же, переход к подобной схеме требует некоторого скачка. Остаётся надеяться, что для него пока не накоплено достаточной базы.

(Эту статью я ранее публиковал на “Хабре”.)

В октябре 2025 года записок на dxdt.ru вышло мало, но я всё же подобрал три записки, которые отмечу отдельно:

• Эмбеддинг с навесом: перегрузка лексических парсеров вложением неявных ссылок
• Техническое: приложения, аутентификация и отпечатки ключей
• Чётность портретов монархов на британских монетах

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

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

Да, на таких японских монетах дата указывается по году периода, и записывается набором из нескольких иероглифических знаков. Если слева направо: обозначение “год”, потом номер самого года, потом – обозначение периода. Например (здесь группы знаков разделены точками, для наглядности): 年 . 七十三 . 治明. То есть, если теперь справа налево, то “Мэйдзи 37-й год”, или 1904 “европейский”. На аверсе монеты 1904 года в 20 сенов дата отчеканена справа от латинского обозначения номинала “20 sen” (см. фото ниже). Именно фотографию аверса и отправили для анализа. Присутствие латинских букв и арабских цифр могло бы помочь ChatGPT, если бы там был “интеллект”, но не помогло. На реверсе же монеты написан только номинал “20 сенов”, но японскими обозначениями: то есть, японские цифры там присутствуют, но это не год.

Аверс монеты – слева на коллаже. Именно эту фотографию и направили в ChatGPT (конечно, в большем разрешении).

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

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

А о том, что вышло бы из ChatGPT после загрузки фотографии реверса, мы в этой записке не узнаем: доступные токены закончились – видимо, картинки потребляют их особенно много.

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

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

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

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

Администраторы настраивают DNS “как получилось”, с ошибками и дефектами – указаны IP-адреса вместо хостнеймов при делегировании, указаны лишние NS, серверы имён не отвечают на запросы SOA и т.д., и т.п. Однако система как-то работает. Только вот попытка использовать эти настройки в более или менее строгом варианте, – например, для проведения проверки права управления доменом (DCV), – наталкивается на эти ошибки и проверка не срабатывает. Потому что есть случаи, когда игнорировать дефекты настройки DNS нельзя. Обнаружение этих “дефектов”, например, может свидетельствовать об идущей атаке.

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

Проблема эта, конечно, не только DNS касается.

На всякий случай: я планирую в обозримом будущем сделать основным именем dxdt.PW – вместо dxdt.RU. Сейчас под dxdt.PW сайта нет (там пока нет A-записи). Замену имени я планирую делать так: заведу dxdt.pw на тот же IP-адрес, который сейчас показывает на веб-узел с dxdt.ru; настрою на этом же веб-сервере универсальный редирект на новое имя: dxdt.ru -> dxdt.pw; постараюсь поменять “титульные” ссылки внутри WordPress, которые сейчас ведут на домен в зоне .ru. После этого веб должен плавно и прозрачно переключиться на новый адрес, в том числе, в части RSS. Обратную зону и почту на dxdt.ru – пока планирую оставить как есть, они не особо важны: комментариев практически нету, рассылки никакие уже давно не ходят.

На аверсе британских монет изображены монархи – короли и королевы, в период правления которых монета отчеканена. Есть старая традиция: портреты соседних, по времени правления, монархов, их профили – смотрят в разные стороны. На иллюстрации ниже – пять монет в один шиллинг разных, последовательных, монархических периодов.

Сразу видно, что чётность нарушена. Монеты разложены по возрастанию года выпуска, слева направо: королева Виктория, король Эдуард VII, король Георг V (это не Николай Второй, это его брат, но двоюродный), король Георг VI, королева Елизавета II. Чётность поворотов профилей нарушена между Георгом V и Георгом VI. Почему?

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

Да, если бы всё пошло по плану, то профиль Эдуарда VIII должен был бы смотреть вправо, а следующий – Георг VI, – смотрит влево. Хитрость в том, что Эдуард VIII вежливо попросил нарушить традицию: он хотел, чтобы его профиль смотрел влево, так как считал, что такое изображение лучше. И именно вариант с поворотом влево и был бы отчеканен массово (не только на тестовых монетах), если бы Эдуард VIII не отрёкся от престола. Как, в таком случае, сложилось бы со следующим профилем – не понятно. Так что, как ни странно, но здесь мы видим физический пример того, как “нуль-проекция” короля сохраняет чётность переходов между разными монетами.

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

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

Что получается с вариантом TLS. Клиент находит IP-адрес сервера через DNS, а проверяет подписи в сертификатах. Ни то, ни другое – не привязаны к серверу. Поэтому, – “внезапно!” – решение оказывается полностью завязано на защиту авторитативных серверов зоны, в которой размещены имена серверов, и DNS-резолвера. Почему? Потому, что если атакующий может подставить IP-адрес своего сервера в ответ DNS, то клиент станет подключаться по TLS к подставному серверу. При этом клиент проверяет только валидность серверного сертификата, то есть, подпись на сертификате должна сходиться к доверенному ключу удостоверяющего центра (УЦ). Но при типовых настройках в этом списке больше сотни УЦ, а контроль над авторитативными серверами DNS (даже над одним) позволяет выпустить сертификат для нужного имени в одном из этих УЦ, например, в Let’s Encrypt. Естественно, речь о системе, которая находится в глобально доступной DNS. Но, скажем, Let’s Encrypt и так повсеместно используется для внутренних имён разных API и тому подобных штук: посмотрите в CT-логи, если хотите убедиться лично.

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

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

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

Теперь вариант с проверкой отпечатков ключей (SSH и прочие решения с key pinning). Значения допустимых ключей прямо задаются и на клиенте, и на сервере. Сейчас принято на клиенте сохранять серверный отпечаток при первом подключении. Но вообще известные отпечатки можно заранее настроить другими способами.

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

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

Промежуточный итог про отпечатки ключей и SSH: из-за того, что тут проверяется конкретный ключ, никакая внешняя подмена не поможет, поэтому схема перестаёт зависеть только от надёжности DNS.

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

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

Естественно, применение ACL на уровне сетей, на уровне виртуализации, сильно затрудняет подмену через DNS. Если доступ наружу открыт только в направлении некоторых “собственных сетей”, то перенаправить соединение на внешний узел просто так не получится. Но, во-первых, ACL могут настраиваться с использованием DNS; во-вторых, если ACL выстраиваются с точностью до IP-адреса (не IP-префикса), то зачем же тогда вообще прописывать хостнеймы? Как бы там ни было, но на описанные разные подходы к аутентификации – ACL не влияют.