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

Как я понимаю, большинство читателей этого блога (dxdt.blog) читают его через RSS-поток. На веб-сраницах трафик тоже есть, – и он заметно больше, – но там, реально, основная часть – это запросы разных ботов, в том числе, LLM-систем. Узел под старым адресом блога, который был в домене .RU, сейчас возвращает универсальный редирект (HTTP 301) на dxdt.blog. Это распространяется и на запросы к RSS-ленте.

И вот смотрю я в логи этого “редиректора” (то есть, на старом адресе dxdt.ru), а там всё ещё немало так GET-запросов именно на RSS-поток. Причём, если верить данным RSS-агрегаторов, которые приходят на старый адрес за RSS, там у них сотни подписчиков. Я вижу, что, после редиректа, эти же RSS-агрегаторы приходят и на dxdt.blog. С одной стороны, неплохо, что они следуют редиректу. Однако, с другой стороны, то, что эти сервисы всё ещё ходят через “редиректор”, означает, что его адрес не был вытеснен новым, а это уже плохо, потому что, как только dxdt.ru будет удалён из DNS, этот трафик, скорее всего, потеряется, а ленты в агрегаторах отломятся.

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

В общем, это я вот к чему написал: сообщение на dxdt.blog – один из двух доступных мне способов проинформировать читателей о замене адреса. Поэтому напоминаю – я перенёс сайт, теперь вместо dxdt.RU стало dxdt.BLOG, если вы читаете через RSS (а это тоже правильно), то вот новый URL RSS-потока: https://dxdt.blog/feed/

Пока есть возможность, я постараюсь старый адрес сохранять с редиректом. Через какое-то время (когда дойдут руки исправить ссылки внутри сайта) я планирую на dxdt.ru выложить по URL RSS-потока отдельную запись, информирующую о том, что поток переехал на другой адрес. Опять же, это всё – если будет возможность: с доменами .RU происходит какая-то неразбериха, что там ожидать – понять я уже не могу.

Ещё раз новый адрес RSS-потока: https://dxdt.blog/feed/

Спасибо, что читаете.

Вот уже два с половиной месяца на dxdt.blog используются короткоживущие TLS-сертификаты от Let’s Encrypt – серверный сертификат валиден 160 часов, новый сертификат, при штатной работе, выпускается каждые двое суток, а старый – отзывается со статусом Superseded. Поделюсь некоторым опытом.

Для короткоживущих сертификатов мониторинг необходим даже больше, чем для “обычных”. Потому что отслеживать нужно событие замены сертификата через каждые два дня: если сертификат не заменился, то “что-то пошло не так” и нужно срочно смотреть, что именно, ведь срок действия сертификата совсем небольшой. Многие типовые решения для мониторинга не приспособлены для короткоживущих сертификатов.

Серверные TLS-сертификаты данного УЦ и данного типа более не содержат имени в поле Subject. Это необходимо учитывать в мониторинге. (Обратите, кстати, внимание на этот момент – как ни странно, но мне до сих пор приходится сталкиваться со скриптами и схемами мониторинга, которые по старинке полагаются на значение Subject серверного сертификата при определении имени. Если в сертификате поле Subject пустое, такие скрипты не просто не работают, но часто вообще начинают действовать неверно – потому что пустое значение даёт интересные эффекты при попытках его обработки. Как переделать shell-скрипты, использующие OpenSSL, описано в одной из записок по теме.)

В остальном – работает неплохо. Кроме dxdt.blog, я нашёл применение для шестидневных сертификатов там, где нужен TLS-сертификат для IP-адреса. Так, у меня есть демонстрационный сайт под IP-адресом: https://185.39.19.199/ – там TLS-сертификат обновляется certbot со штатными настройками. Также я использую TLS-сертификаты для IP-адресов на некотором DNS-стенде, где такие сертификаты очень хорошо подходят для авторитативных серверов DNS (DNS over TLS: см., например, тестовый сервис для резолверов dns.1d.pw).

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

С доверием тут проблема не только в браузерах. Сертификатам этим вообще доверяют не все пользователи. В связи с этим сейчас много где рекомендуется некоторый весьма технический метод установки “сертификатов Минцифры”, но с ограничением по допустимым именам хостов, чтобы сертификаты от данного корня считались валидными только для некоторых имён, предположим, для имён только в зоне .RU, или для имён только в DNS-зоне банковсого сайта. Это боязнь атаки типа MITM: технически, всякий УЦ может выпустить сертификат для любого имени.

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

Вообще, цель этой записки в другом: объяснить, что это всё означает, почему и как работает. Речь здесь пойдёт про веб-браузеры и TLS в HTTPS.

Итак, упомянутая выше схема “переподписывания” давно известна среди специалистов, она вполне штатная, и называется “кросс-подпись”. Логика алгоритма в том, что открытый ключ из целевого “корневого сертификата”, – обозначим его литерой “Б”, – подписывается ключом доверенного УЦ, а получившийся новый сертификат содержит такой же открытый ключ, как сертификат “Б”, и такое же имя в поле Subject. По такой схеме долгое время в браузерах работал УЦ Let’s Encrypt (да и сейчас есть сертификаты для корневых ключей Let’s Encrypt, выпущенные от других УЦ, это улучшает совместимость).

Почему кросс-подпись работает? Потому что в ходе валидации серверного сертификата цепочка строится по именам (Issuer <===> Subject), а подписи проверяются по открытым ключам из сертификатов цепочки. Часть цепочки – присылает сервер, а доверенный корень – встроен в браузер. Чтобы сертификат был признан валидным, необходимо (но не достаточно), чтобы цепочка пришла к доверенному ключу. Но нет разницы, что это за ключ и откуда он – главное, чтобы он был доверенным. Поэтому прочие данные из TLS-сертификата всегда играют вспомогательную роль, главное, что есть в сертификате – открытый ключ. Поэтому и сертификаты строго называют “сертификатами ключей”.

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

Оказывается, этот момент регулярно ускользает из поля внимания даже технически продвинутых пользователей, а в результате – теряется понимание процесса.

Рассмотрим очень подробный пример.

Пусть сервер адресуется именем example.com. Для example.com выпущен оконечный (серверный) сертификат от ключа промежуточного УЦ под названием Interm-CA-1. Для открытого ключа этого УЦ Interm-CA-1 выпущен сертификат “корневым УЦ” Root-CA-1. И открытый ключ Root-CA-1 встроен в браузер. Браузер доверяет открытому ключу Root-CA-1. Этот открытый ключ непосредственно указан в сертификате Root-CA-1. Тогда браузер выстраивает цепочку example.com <- Interm-CA-1 <- Root-CA-1, проверяет подписи от Root-CA-1 на Interm-CA-1, а от Interm-CA-1 на example.com и, если всё сошлось, распространяет доверие по цепочке до сертификата example.com. Это обычный способ, без кросс-подписи.

Теперь представьте, что в браузере есть и Root-CA-2, тоже доверенный. Пусть Root-CA-2 выпустил и подписал сертификат для того же открытого ключа, который указан в сертификате Root-CA-1. “Обычный” сертификат корневого ключа Root-CA-1, который упоминался выше, – это самоподписанный сертификат, то есть, подпись в нём от того же ключа, открытая часть которого указана в сертификате. Новый сертификат, выпущенный для ключа Root-CA-1 не является самоподписанным – его подписал Root-CA-2, используя другой ключ.

Обратите внимание: открытый ключ в этом новом сертификате – тот же, что и в самоподписанном сертификате корневого ключа Root-CA-1. Это подпись другая. Соответственно, этот открытый ключ позволит успешно проверить подпись, поставленную Root-CA-1 на сертификате Interm-CA-1 из цепочки, описанной выше. Более того, когда УЦ Root-CA-2 генерировал сертификат для ключа Root-CA-1, то этот УЦ и в качестве имени Subject сертификата указал Root-CA-1. Но Issuer – отличается: здесь стоит Root-CA-2 (в самоподписанном исходном и Issuer, и Subject – были Root-CA-1). Браузер верит ключу Root-CA-2. Теперь возможна другая цепочка: example.com <- Interm-CA-1 <- {Root-CA-1} <- Root-CA-2. Цепочка ведёт к Root-CA-2, он доверенный. Сертификат в фигурных скобках {Root-CA-1} – это сертификат для того же открытого ключа, от Root-CA-1, но выпущен он Root-CA-2. А раз это тот же ключ, то и для сертификатов, которые в цепочке находятся левее {Root-CA-1} ничего не поменялось – доверие транслируется точно так же. Это и есть кросс-подпись.

В схеме кросс-подписи больше не нужен доверенный корневой самоподписанный сертификат Root-CA-1. Его не нужно ставить в браузер вообще, потому что доверие транслируется от Root-CA-2 через кросс-подпись, поставленную на ключе, а не “на исходном сертификате”, как почему-то иногда пишут. Нет, исходный корневой сертификат не “переподписывается” – из него просто берётся открытый ключ, а далее доверие этому ключу образуется при помощи его подписывания собственным, локальным корневым ключом. И в браузер добавляется доверие этому, корневому ключу. Естестсвенно, необходим {Root-CA-1} (в фигурных скобках), выпущенный Root-CA-2. Этот сертификат (в фигурных скобках) локальный, его не пришлёт сервер. Поэтому сертификат придётся добавить в браузер (если для этого сертификата установить флаг доверия, то не нужен уже Root-CA-2, кстати. Но см. ниже про целевые ограничения – их нельзя утрачивать.)

Где же здесь ограничения? Они в nameConstraints. В TLS-сертификатах есть штатный способ, который позволяет описать ограничения по именам, для которых применим ключ из сертификата. Обратите внимание на важный момент: это механизм описания, он вовсе никак не позволяет “реализовать ограничение”. Реализация – остаётся на стороне валидатора сертификатов. То есть, если браузер применяет ограничения из блока сертификата nameConstraints, то сертификат не будет считаться валидным для имён, за пределами списка, если не применяет – будет. Современные браузеры nameConstraints обрабатывают и ограничения применяют. В частности, Firefox действует даже строже, чем предписывают RFC, касающиеся этих ограничений.

Механизм ограничения валидности довольно прост: в поле nameConstraints перечисляются наборы DNS-имён для которых разрешено или запрещено применять ключ при проверке подписи. Прежде всего, данное поле предназначено для сертификатов ключей УЦ. То есть, для ключей, от которых выпускаются другие сертификаты. При корректном применении ограничения должны действовать по всей цепочке вниз. Например, если в корневом сертификате указано ограничение “разрешено только для example.com”, то валидатор, следующий ограничениям, не примет сертификат от этого корня для example.net. Цепочка проверки при этом может включать несколько промежуточных сертификатов. Ограничения по именам применяются и тогда, когда в сертификате этих имён много: все имена должны быть разрешены, иначе валидация не пройдёт. То есть, при правильной реализации, метод весьма действенный.

Теперь, если мы подписываем кросс-подписью ключ другого УЦ, то мы можем указать нужные ограничения в сертификате, который подписываем. Ограничения перечисляются в nameConstraints. В принципе, ограничения можно указать и сразу в локальном сертификате корневого ключа. В качестве состава ограничений может быть как только конкретный домен верхнего уровня, так и конкретные DNS-имена веб-сайтов. Тогда браузер посчитает невалидными оконечные сертификаты, выпущенные от исходного корневого ключа, но для имён, которые не входят в разрешённый список. Предполагается, что это противодействует потенциальным MITM-атакам: “ограниченный” корневой сертификат уже не позволит браузеру посчитать валидным оконечный сертификат, выпущенный для, условно, google.com. Заметьте, впрочем, что у Chrome и Google есть специальные меры, отслеживающие подобную подмену без всяких nameConstarints и собственного локального корня. При этом локальный корень, налаженный по описанной схеме в том же Chrome, данные меры поломает, поскольку всё будет выглядеть так, как если бы в систему установлен “сертификат корпоративного УЦ”, а для таких случаев многие способы детектирования подмены серверных ключей работают не так строго. Это один из неочевидных аспектов использования данного решения.

Итак, схема сводится к следующим шагам: 1) генерируем собственный корневой секретный ключ и сертификат для этого ключа с ограничениями по именам в nameConstraints; 2) встраиваем в браузер открытую часть данного ключа в качестве доверенного; 3) выпускаем от этого корневого ключа сертификат кросс-подписи для ключа из “сертификата Минцифры”, совпадающий по имени Issuer с “оригинальным”, возможно, повторяем тут ограничения по именам, добавляем этот сертификат тоже в доверенные. “Сертификат Минцифры” – добавлять не нужно, уже добавлен ключ из него. Всё. Теперь браузером начинают считаться доверенными сертификаты только на сайтах, подходящих по именам.

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

Заметьте, кстати, что если на локальном компьютре установлен антивирус, перехватывающий TLS-соединения браузера, то все описанные манипуляции с сертификатами никак не повлияют на реальное положение дел с валидацией.

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

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

Ближайшее будущее в области TLS-сертификатов для веба – это сертификаты на хеш-деревьях. Я писал об этом неоднократно. Ещё одно подтверждение: черновик политики Google по включению в список доверенных удостоверяющих центров (УЦ) веб-браузера Chrome. Этот черновик касается постквантовых криптосистем цифровой подписи (или, как их ещё обозначают, “квантовостойких” криптосистем). В контексте данной программы доверенных УЦ Chrome – это криптосистема ML-DSA (и только). Но главное тут не тип криптосистемы, а то, что политика допускает исключительно схему с хеш-деревьями, с MTC (Merkle Tree Certificates). Соответственно, УЦ, не поддерживающие MTC – в программу даже податься не смогут, вне зависимости от других параметров. MTC, с точки зрения УЦ, совсем другая история, если сранивать с имеющимся сейчас вариантом.

Этот вариант, – хеш-деревья, – алгоритмически близок с реализации Certificate Transparency (CT). Концептуально, MTC – это перенос CT на сторону УЦ. Поэтому в черновике политики прямо сказано, что на начальном этапе включение в “квантовостойкие корни браузера” будет доступно только для тех организаций, которые уже поддерживают работоспособный лог CT (то есть, запустили такой лог до 1 февраля 2026 года). К таким организация, естественно, относятся Let’s Encrypt, Cloudflare и Google (но не только эти).

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

Небольшое сообщение: если у вас вдруг сохранились мои весьма старые адреса e-mail, которые на .RU, то лучше их не использовать для отправки почты мне, а использовать те, что не в .RU (см. например, на сайте в блоке информации справа). Опубликованный PGP.ASC, если это кому-то важно, я поправил, удалил оттуда .RU (ключ тот же; кстати, мне, вообще, PGP/gpg не очень-то нравится, но ключ я держу опубликованным, по историческим причинам – им редко кто пользуется, и он только для почты).

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

Кстати, в доменной зоне google.com есть TXT-запись со значением “Z29vZ2xl”. Проверьте:

$ dig -t TXT google.com +short | grep 'Z29'
"Z29vZ2xl"

“Z29vZ2xl” это ASCII-представление строки “google” в Base64.

$ echo -n "google" | base64
Z29vZ2xl

Кстати, что касается обнаружения отзыва серверных TLS-сертификатов. Ещё раз подчеркну – речь здесь об оконечных, о серверных TLS-сертификатах. С сертификатами УЦ – ситуация отличается. Итак, для оконечных сертификатов, сейчас, согласно требованиям CA/B-форума, есть три базовых способа публикации статуса сертификата и несколько вариантов их комбинирования:
1) публикация CRL;
2) OCSP-респондер;
3) ничего (то есть, нет точки публикации информации о статусе сертификата).

Итак, первый вариант, CRL: файлы CRL выкладываются на точку раздачи, доступную по HTTP, откуда их можно скачивать; URL указывается в составе сертификата (отдельное поле). В ряде случаев применяется различный “шардинг” и множественные URL. Например, Let’s Encrypt использует для одного и того же поколения сертификатов и промежуточного УЦ большое количество разных имён CRL (они именованы порядковым номером: 1, 2, 3, …, 128). В сертификате может быть указано несколько точек раздачи CRL, с разными URL. Это важный аспект.

Второй вариант, OCSP: OCSP давно перевели в разряд опциональных, но данный протокол всё равно используется; и если используется, то публикуется точка доступа к OCSP-респондеру (на практике, транспортом тоже будет HTTP), URL указывается в сертификате (отдельное поле, отличается от поля для CRL). Может быть несколько URL OCSP.

Третий вариант, самый интересный: в сертификате вовсе не указано способа получения информации о статусе. Такое уже довольно давно допускается, но только для “короткоживущих” (short-lived) сертификатов. Сейчас, “короткоживущий” – это со сроком валидности не более семи суток (604,800 секунд). Поэтому, например, в шестидневных сертификатах Let’s Encrypt может вообще не быть ни CRL, ни OCSP. Ну, OCSP вы там точно не найдёте – в Let’s Encrypt давно перестали его предоставлять; а вот CRL – пока что найти можно, но заметьте, что это опционально.

Теперь, что касается комбинирования. В сертификате всё ещё может быть указан адрес OCSP-респондера, но не указан адрес CRL! То есть, встречаются корректные и валидные сертификаты, статус которых только по OCSP возможно определить, адреса точки раздачи CRL в них нет вовсе. Могут быть указаны и OCSP, и CRL. И может быть только CRL. То есть, если сертификат не “короткоживущий”, то CRL является обязательным, но только в том случае, если нет OCSP (который опционален).

В рамках определения статуса сертификата нужно аккуратно обрабатывать все варианты. Например, если в сертификате указано несколько точек раздачи CRL, то тот факт, что в CRL, полученном от одной из точек, серийного номера сертификата нет, не означает, что сертификат не отозван: его серийный номер может присутствовать в другом файле CRL. Проверять отсутствие нужно по всем CRL. Когда указан OCSP-респондер (или несколько), то нужно и его тоже проверить, если сертификат не нашёлся в CRL.

В Cloudflare на днях обновили свой сервис мониторинга логов Certificate Transparency (CT). Мониторинг отслеживает публикацию в логах (пре)сертификатов для заданного доменного имени. Напомню, что в прошлом году ни наличие сервиса мониторинга, ни наличие собственных логов CT, не помогли Cloudflare в течение нескольких месяцев выявить неавторизованный выпуск TLS-сертификатов для собственного же сервиса 1.1.1.1 (один из самых известных сервисов Cloudflare). Возможно, какие-то выводы были сделаны. Однако в этом контексте текущее обновление сервиса мониторинга CT выглядит ещё более странным. Дело в том, что это обновление отключает вывод оповещений о сертификтах, выпущенных системами Cloudflare. И делает это при помощи фильтра по открытым ключам.

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

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

То есть, то, что Cloudflare отслеживает и фильтрует сертификаты по ключу, не означает, что отслеживаются только сертификаты, выпущенные по запросу систем Cloudflare. Это совсем разные вещи, но про это Cloudflare не сообщает. Поскольку выпуск сертификата не требует секретного ключа, то, технически, какой угодно УЦ может выпустить сертификат для того же серверного открытого ключа, что использует и Cloudflare. Однако мониторинг CT, если верить описанию, этот сертификат не покажет. Проверка подписи в CSR и пр. – это, да, это всё привычные шаги, но, ещё раз, технически они никак на выпуск сертификата не влияют.

Конечно, такой выпуск сертификата для произвольного ключа – возможность весьма теоретическая, не поспорить: да, для выпуска секретный ключ не нужен, но, как минимум, чтобы использовать подобный “подменный” сертификат – тут секретный ключ уже потребуется. Это, однако, не отменяет странной подмены понятий: совпадающий открытый ключ – вообще никак не означает, что сертификат был выпущен по запросу систем Cloudflare, утверждать такое – ошибка.

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

Как именно отпечатки ключей используются? Возможно ли их “просачивание” между аккаунтами? Непонятно. Если такое возможно, то Cloudflare может использовать тот же открытй ключ, но для разных имён и, соответственно, разных сертификатов, хотя бы и по ошибке. Сертификаты будут опубликованы в CT-логах, но фильтрация по значению ключа такое не покажет.

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

В общем, получилась подмена базовой концепции. Формулировка базового вопроса, стоящего за подобным мониторингом CT, такая: разрешил ли администратор имени выпуск этого конкретного сертификта? Но, получается, что её “незаметно” подменили на другую: узнаёт ли сервис Cloudflare данный открытый ключ из сертификата? Почувствуйте, как говорится, разницу.

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

Между тем, под видом борьбы с AI-ботами уже предлагают полностью сломать веб. Вот до чего уже дошло. Проект ShieldFont при помощи шрифтовой подстановки заменяет одни слова на другие.

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

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

Забавно, что в описании такая “замена слов” называется заменой на “лигатуру”, но, естественно, это не лигатура никакая: конечно, лигатура может соответствовать короткому слову, но не наоборот – произвольное слово не может стать лигатурой, чтобы “помешать боту”, потому что лигатура – это про буквы. И ещё более забавно, что, если верить репозиторию с кодом проекта на Github, в разработке использовалась LLM-система Claude.

Для некоторых доменов в .ru, которые ранее я зарегистрировал, регистрация закончилась. Соответственно, они переделегируются на специальные NS регистраторов. Продлевать регистрацию я не планирую – не вижу смысла: ЕСИА, да ещё и цены стали совсем немалые. Сегодня вот пришлось заниматься экстренным удалением одного из технических имён .ru, которое я не успел раньше вычеркнуть из DNS-зон, а оно, оказывается, уже закончилось. Вроде, тоже поправил. На dxdt.blog это не должно было повлиять, но всё же.

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

Удивительное всё же дело. Но, надеюсь, что хотя бы управление другими доменами, которые не в .ru, .su, .рф, пока останется. Посмотрим.

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

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

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

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

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

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

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

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

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