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 этот текст позже находит и связывает с пользовательской сессией. Теперь провайдер сервиса знает, какие пользователи для чего тексты генерируют. Соответственно, может вносить нужные изменения, оказывая прямое влияние на результат.

Появилась новая публикация (Daniel R. Simon), предлагающая квантовый алгоритм, взламывающий – теоретически! – криптосистемы типа ML-KEM/ML-DSA за полиномиальное время (то есть, атака предложена на задачу, лежащую в основе предположения о стойкости, в том числе, ML-KEM/ML-DSA, но подходит не только для них). Для работы алгоритма потребуется подходящий квантовый компьютер – уже этим многое сказано. Однако пока что и сама работа опубликована в статусе черновика, о чём там прямо сказано. То есть, скорее всего, – найдутся ошибки.

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

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

Что будет означать появление описания квантового алгоритма, эффективно взламывающего ML-KEM/ML-DSA и другие криптосистемы под собирательным обозначением “на решётках”? Это точно не приблизит к реальности сами универсальные квантовые компьютеры, но зато создаст вполне себе хорошее обоснование для того, чтобы либо улучшать стойкость ML-KEM/ML-DSA и прочих “решёточных” криптосистем, либо переходить на другие криптосистемы. И это будет весьма забавно: для атаки на постквантовые криптосистемы предложены новые теоретические квантовые алгоритмы, поэтому нужны суперпостквантовые криптосистемы, устойчивые и к алгоритму Шора, и к новому алгоритму “Имярек”.

Посмотрим, в общем, что там предложат. Так или иначе, но считать ML-KEM/ML-DSA неприступными – точно ещё рано.

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

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

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

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

Let’s Encrypt сейчас предоставляет только один интерфейс для проверки статуса сертификата – списки отозванных сертификатов (CRL-файлы, адреса точек раздачи которых указаны в самом сертификате). От OCSP-респондера давно отказались (и совершенно правильно сделали: OCSP – так себе технология). Собственно, для “сверхкоротких” TLS-сертификатов сейчас вообще допускается отсутствие информации о статусе, то есть, можно и CRL не публиковать. Let’s Encrypt пока что публикуют.

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

На практике это не всегда так – сертификатов отзывается мало, потому что, вообще говоря, отзыв сертификата – не считается штатным событием. (Но, тем не менее, я таки стал отзывать каждый короткоживущий сертификат, до истечения его срока действия – но то больше в качестве эксперимента.) Всё же, чтобы, видимо, как-то подготовиться к потенциальному “распуханию” списков отзыва, Let’s Encrypt использует некий “шардинг” – CRL для одного УЦ нарезаны на несколько файлов (судя по всему, на 128): например, есть точка раздачи по адресу http://ye1.c.lencr.org/108.crl, а есть и http://ye1.c.lencr.org/18.crl, и 10.crl и т.д., думаю, схема именования ясна. Это всё CRL от УЦ YE1 (как видно и по имени хоста). Конкретный адрес, с разным “фрагментом” CRL, пишется в конкретный оконечный сертификат. Например, сейчас в сертификате на dxdt.blog указана точка http://ye2.c.lencr.org/103.crl.

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

В ACME предусмотрено три основных способа такого “связывания”:
1) через ACME-аккаунт – то есть, запросить отзыв может тот же аккаунт, под которым отзываемый сертификат был получен от УЦ;
2) через секретный ключ от открытого, указанного в сертификате – то есть, любой аккаунт может отозвать сертификат, если запрос подписан секретным ключом от сертификата (это понятный и самый строгий механизм: если секретный ключ от сертификата скомпрометирован, то единственное, где подписи от этого ключа ещё можно доверять, это запрос на отзыв соответствующего сертификата);
3) через подтверждение права управления именем (DCV) – если ACME-аккаунт подтвердил, что управляет именем, указанным в сертификате, то этот аккаунт может отозвать любой сертификат, выпущенный УЦ для подтверждённого имени; тоже логичное решение – сторона, фактически управляющая доменом (или IP-адресом), должна иметь возможность отозвать “прошлые” или “старые” сертификаты.

Заметьте, кстати, что третий метод позволяет отозвать любой сертификат, где единственное подтверждённое имя указано в списке имён (то есть, можно отозвать сертификаты, в которых есть ещё какие-то другие имена/адреса в SAN).

Я сейчас отзываю “замещённые” сертификаты dxdt.blog просто тем же ACME-аккаунтом.

Вот уже месяц сайт dxdt.blog работает на “короткоживущих” TLS-сертификатах Let’s Encrypt. Эти сертификаты валидны, примерно, шесть с половиной дней (160 часов). Соответственно, новые сертификаты заказывает автомат через API ACME (утилита certbot, в данном случае), с периодичностью один раз в двое суток.

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

То есть, в принципе, всё сделано типовым способом и пока что работает нормально. Продолжаем наблюдать.

В Cloudflare сделали для резолвера 1.1.1.1 выдачу DNS-сигнала о том, что для заданного имени на резолвере отключена валидация DNSSEC. Речь идёт про использование так называемых NTA (Negative Trust Anchor) – это способ, позволяющий избирательно отключать валидацию DNSSEC-записей, который должен применяться в исключительных случаях, например, если DNSSEC поломалась в целой зоне первого уровня – как, всего за минувшие пару пару лет, происходило и с .RU, и с .DE, и вот совсем недавно с .AL (Албания). Сигнал об использовании NTA передаётся в расширенных кодах ошибок DNS. Нельзя сказать, что это прямо вот совсем не очередной “костыль” в процессах DNSSEC, потому что на “костыль” всё равно очень похоже, но всё же это сильно лучше, чем просто DNSSEC-валидацию тихо отключать, если “ой, оно опять сломалось”.

Кстати, о поломках DNSSEC и реалиях “технического совершенства” современных интернетов. Вот я только что привёл примеры недавних фатальных сбоев DNSSEC. И среди этих примеров: .RU и .DE. Оба – крупнейшие ccTLD. Домен Германии .DE – вообще на первом месте по количеству зарегистрированных имён, .RU – входит в пятёрку. Имён – миллионы. То есть, это давно уже не про то, что сломался какой-то где-то забытый страновой домен. Вовсе нет. Так что проблема с внедрением DNSSEC – вполне себе масштабная. Да и не только с DNSSEC, конечно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

1.

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

2.

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

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

***

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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