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

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

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

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

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

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

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

Пишут, что в Microsoft запускают исследовательский проект по созданию ИИ-инструмента для “автоматизированного переписывания” программного кода с C/C++ на Rust. Зачем? А затем, “чтобы избавиться от C-кода” (что само по себе очень и очень забавно, особенно, если вспомнить, что уже и компилятор – это автоматизированный инструмент для перевода кода с того же Rust в машинные команды целевой платформы).

Вообще, исходное сообщение из Microsoft – оно про найм главного инженера-программиста, который мог бы этим (созданием проекта) заняться. Так что это далеко ещё не проект. Тем не менее, если исключить buzzwords, то занимательно звучит главная цель: миллион строк кода в месяц усилиями одного инженера. Это, на минуточку, получается около 6000 строк кода в час. Учитывайте, что это на каждом из языков, то есть, фактически, в два раза больше. Как инженер может читать, понимать и исправлять непрерывно (в рабочее время, конечно) по 6000 строк кода в час параллельно на каждом из языков (C/C++ – Rust) – этот момент, к сожалению, не объясняется. Но, скорее всего, понимать код и не требуется, раз его генерирует ИИ – достаточно уметь нажимать на кнопку Approve в “мёрдж-реквесте”.

Кругом buzzwords про ИИ. Некоторых эти самые buzzwords уже пугают. Вот и до Firefox добрались: в новом “стратегическом сообщении” пишут, что переделают Firefox в “современный ИИ-браузер” (“It will evolve into a modern AI browser and support a portfolio of new and trusted software additions”).

С одной стороны, понятно, что это просто дежурная штамп-фраза, без которой сейчас никуда в области корпоративных пресс-релизов. С другой стороны, для Firefox, конкретно, звучит оно пугающе. ИИ-хайп настолько уже велик, что подкладывают его везде. Нормального ПО нынче всё меньше. Почему? Потому что – ну, как же! – “ИИ полностью трансформировал разработку!”. Тут того и гляди линуксовое ядро начнут превращать в “ИИ-агента”, а там и до FreeBSD доберутся. Так что браузеров-то и подавно, считай, не осталось уже.

В продолжение предыдущей записки. Ещё один занятный момент про сверхкороткие TLS-сертификаты.

Понятно, что если сертификаты действуют недолго, то на заданном интервале времени сертификатов будет больше. Например, больше сертификатов будут попадать в логи Certificate Transparency (CT-логи). Возникнет дополнительное зашумление: если для домена example.com за месяц выпущено десять сертификатов вместо двух, как раньше, то запутаться с обработкой и мониторингом проще.

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

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

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

В IETF и вокруг сейчас происходит небольшой технический скандал, непосредственно связанный с внедрением рекомендаций по использванию негибридных криптосистем ML-KEM в TLS.

Если очень кратко, то переход на постквантовую криптосистему ML-KEM, как единственный механизм получения сеансового секрета, может восприниматься как попытка протолкнуть в TLS некий бэкдор, который отсутствует в X25519 (сейчас X25519 используется вместе с ML-KEM, в составе гибридной криптосистемы, поэтому бэкдор в ML-KEM, для гибрида, только лишь снизит стойкость в два раза).

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

Что имеется в виду? Вот что: якобы, если множество вариантов параметров криптосистемы достаточно маленькое, чтобы перебрать его за обозримое время, то бэкдор там негде прятать – его можно будет обнаружить простым перебором. И вот в ML-KEM, как бы, это множество – всего 34 бита. Как бы, утверждение верное, вот только оно сильно слабее, чем предположение о бэкдоре: бэкдор может находиться непосредственно в алгоритмах, поэтому, для его обнаружения прямым перебором, нужно будет мощность множества параметров возвести в некоторую большую степень (это, примерно, как идея моделирования квантовых вычислений, когда у вас все 2^34 варианта участвуют в расчётах на каждом шаге).

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

Вообще, конечно, история, в которой ML-KEM почему-то начинают тщательно “обелять”, доказывая, что там нет бэкдора – несколько подозрительная.

Кстати, так как SCT-метка в сертификате – это только дополнительная подпись, то возможность взламывать криптосистему подписи позволяет сгенерировать и TLS-сертификат, и валидную SCT-метку в нём. Логи Certificate Transparency тут никак не мешают.

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

Естественно, зная секретный ключ УЦ, можно просто пойти и получить валидную SCT-метку непосредственно от оператора CT-лога, не взламывая ключи этого оператора. Но, предположим, тогда (пре)сертификат всё же будет опубликован.

Что это означает? Это означает, что возможность глобально ломать ECDSA никак CT-логами не блокируется. Почему-то про это постоянно забывают.

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

Процитирую фрагмент по этой теме из моего технического описания TLS:

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

Сейчас почти весь 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.

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

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

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

В продолжение предыдущей записки. Два подхода к аутентификации сервисов и приложений – по отпечатку (значению) открытого ключа и по 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 не влияют.