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

В рамках “ренейминга”, связанного с миграцией сайта с доменов .ru, сделал субординатные имена авторитатвиных серверов DNS для dxdt.blog. “Субординатные” – означает, что имена авторитативных серверов (NS) находятся в той же зоне, которая делегирована на эти серверы: например, ns1.example.com, ns2.example.com для example.com. Такую схему именования ещё иногда называют “красивые NSы”. В случае dxdt.blog, имена NS-ов – в зоне dxdt.blog.

Соответственно, делегирующий ответ с такими именами обязательно содержит так называемые glue-записи – то есть, записи с информацией об IP-адресах NSов. Иначе рекурсивный опрос не будет работать, так как зациклится. Я об этом писал неоднократно, в том числе, про сложную рекурсию, связанную с перекрёстными зависимостями.

Например, сама зона .blog размещена на NS-ах с субординатными именами:

alex@garlic-crusher:~$ dig blog. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
blog.			172800	IN	NS	a.ns.nic.blog.
blog.			172800	IN	NS	d.ns.nic.blog.
blog.			172800	IN	NS	c.ns.nic.blog.
blog.			172800	IN	NS	b.ns.nic.blog.

;; ADDITIONAL SECTION:
[...]

– здесь имена авторитативных серверов в ns.nic.blog., пусть для корневой зоны это и не имееет большого значения (см. ниже). Да, субординатные имена популярны, однако мне подобная схема именования не очень нравится. Другой вариант, из зон верхнего уровня, можно наблюдать в .ru:

alex@garlic-crusher:~$ dig ru. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.

;; ADDITIONAL SECTION:
[...]

Однако, если говорить строго, то окажется, что любое имя в глобальной DNS Интернета так или иначе связано с “субординатными” NS-ами: потому что в делегирующих ответах, в качестве основного состава, могут быть только хостнеймы – имена серверов, и в какой-то момент рекурсивного опроса DNS обязательно возникнет проблема “курицы и яйца”. Более того, в DNS наступление такой проблемы можно откладывать до уровня корневой зоны, но вот IP-адреса серверов корневой зоны – распространяются по рекурсивным резолверам тем или иным способом, отличным от DNS (исторически – это всем известный hints-файл), именно для того, чтобы система заработала при первоначальном запуске.

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

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

Самое интересное в озвученных планах, что на середину 2027 года (следующий год) запланирована защита постквантовыми криптосистемами цепочки аутентификации для подключающихся клиентов – это, как указано, сертификаты на хеш-деревьях (с ML-DSA, скорее всего). (MID 2027: PQ authentication support for visitor → Cloudflare connections using Merkle Tree Certificates.)

В Google недавно намекали на то, что поддержка постквантовых криптосистем подписи для TLS и X.509-сертификатов появится в Chrome/Chromium уже к концу 2026 года. И в это можно поверить, потому что сами технические средства в виде программного кода и описаний структур – довольно давно готовы, а полная реализация имеющимися средствами конкретно для TLS-сертификатов неоднократно продемонстрирована на практике.

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

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

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

Да, нужна поддержка на стороне обычных серверов, в виде утилит для выпуска ключей и запросов на сертификаты всеми желающими. То есть, обычный сейчас вариант с ECDSA или RSA – не подходит: эти криптосистемы не обладают постквантовой стойкостью, теряется смысл даже в том случае, если УЦ подписывает постквантовой криптосистемой. Вручную же ключи генерировать могут не все, а тем более – использовать в веб-сервере. Нужны автоматические утилиты. Однако, распространение ACME-автоматизации – certbot и пр. – позволяет процесс автоматизировать и тут, сведя весь переход к обновлению версий системных библиотек и скриптов для заказа сертификатов через ACME. И веб-сервер придётся обновить, конечно.

В общем, не выглядит неральным, но посмотрим.

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

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

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

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

В свежей версии 149 браузера Firefox добавлен встроенный VPN-сервис, заворачивающий трафик к веб-узлам в туннель, проходящий через “прокси-сеть” Mozilla. Такой сервис был обещан некоторое время назад, теперь его постепенно внедряют в основную ветку браузера.

Тут как раз очень важно то, что вся обработка и перенаправление трафика – происходят в браузере. То есть, веб-узел видит только IP-адрес оконечного узла туннеля. А промежуточные сетевые узлы, находящиеся между браузером и входным узлом наложенной “прокси-сети”, не видят IP-адрес веб-узла, с которым соединяется браузер. Добавьте сюда защищённый DoH/DoT резолвинг DNS и – получается закрытая специализированная сеть доступа, привязанная к браузеру. Но пока что такой VPN-доступ не для всех, а только для пользователей в США, Великобритании, Германии и Франции.

Кстати, на d-russia.ru – сообщение про новые правила (проект) регистрации доменных имён .RU, .SU, .РФ. Если прочитать сами правила, то там, как и ожидалось, буквально везде требуется идентификация через ЕСИА, даже для делегирования имени, не то что при регистрации, продлении регистрации или при передаче права управления.

Когда-то, благодаря старому регистратору RU-CENTER, издавался такой замечательный, уникальный журнал – “Доменные имена”. Журнал выходил в печатном варианте, оформляли и верстали его, ни много ни мало, а в Ателье “Афиши”. У журнала был собственный заказной шрифт, особая бумага и удивительный дизайн каждого номера. А я некоторое время был главным редактором, так что хорошо помню процесс. Нынче даже и сайт журнала уничтожен (до сих пор не могу понять – почему).

Но сейчас не об этом.

Вот в 2012 году мы с Артемием Ломовым написали для этого журнала (ДИ, 2012/1(6)) занятную статью – “Сценарии конца Интернета”. Я на эту статью несколько раз уже ссылался на dxdt.ru. Интересно, что некоторые моменты из статьи стали сбываться, – частично, конечно, – прямо на следующий год после публикации. Например, сценарий про “Красную кнопку”. В статье упомянуты и “белые списки”, правда – в контексте “борьбы за копирайт”. В общем, дальше – пошло и поехало.

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

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

“А возможно, никакой технологической сингулярности не случится: как мы разобрались, есть угроза утраты человечеством инженерных навыков, поэтому разумные машины строить будет некому. В таком случае люди могут просто заскучать от «всех этих ваших интернетов», потерять интерес к компьютерам — и в результате мягкого глобального помешательства Сеть больше не нужна никому, сайты заброшены и не обновляются, замерз на ленте последний твит никому не известного жителя Техаса. Некоторое время разнообразные спам-боты и генераторы контента еще продолжат наполнять базы данных бессвязным текстовым бредом, предназначенным для чтения роботами поисковых машин, но потом потухнет и эта активность.

Опустевший Интернет завершил существование.”

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

Как я уже выше отметил – сайт журнала, который находился в домене nic.ru, уничтожен, и довольно давно. Поэтому даже и ссылку дать не получится: бумажные номера остались, но они – без гипертекста.

Кстати, прошлый заход “борьбы с Telegram”, который был весной 2018 года, привёл к тому, что сайт dxdt.ru был довольно длительное время недоступен из сетей российских провайдеров (Telegram, конечно, продолжал работать).

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

Переносить тогда сайт и заменять основные IP-адреса – я не стал, но зато пришлось добавить IP-адресов для того, чтобы был какой-то доступ по HTTPS: это кратко описано в записке из тех времён.

Кстати, вот ещё из очевидного “творчества” ИИ/LLM – попалось на “Хабре” (где, похоже, результатов генерации LLM, – “ИИ-помоев”, – только становится больше), дословная цитата:

“TXT-запись — это произвольная строка текста привязанная к домену. Придумали её для SPF (верификация почтовых серверов) и DKIM, потом стали использовать для подтверждения владения доменом в Google Search Console и Let’s Encrypt.”

На минуточку: TXT-записи – описаны в RFC 1035, это 1987 год, однако сама концепция размещения TXT-записей – ещё старше. Никакого SPF, – а тем более, DKIM, – тогда ещё не было, и никто не придумывал TXT-записи для SPF и DKIM.

SPF (эта технология оформилась в начале 2000-х годов, TXT-записи уже были) – вообще первоначально использовала отдельный специальный тип DNS-записи (SPF-запись), который сейчас отнесён к устаревшим, а данные SPF, действительно, сейчас размещаются в TXT-записях, но из этого не следует, что TXT-записи “придумывали для SPF”. DKIM – та же история, только ещё более свежая, из 2007-2011 (исходный документ RFC 4870 – это 2007 год, но данный RFC сейчас имеет статус “исторического” и не применяется).

Ну и забавно выглядит утверждение, что “потом стали использовать для подтверждения владения доменом” – то есть, вообще не верно: подтверждение с помощью TXT-записи применялось раньше и независимо от SPF/DKIM.

Понятно, что LLM это всё неведомо, так как LLM просто генерирует текст, а проверить его на соответствие реальности – просто некому. Дальше это всё попадает через “Хабр” в “поисковые системы”, которые, так как “Хабр” считается авторитетным, опять загоняют это всё в LLM и показывают пользователям, уже “со ссылками”. Поэтому-то результат и печалит.

В 2023 году я писал на dxdt.ru об одном из эффективных, для DNSSEC, способов динамического удостоверения факта отсутствия DNS-записи (или DNS-имени), который, в частности, применяют в Cloudflare. В конце 2025 года этот способ, с некоторыми добавлениями и обновлениями, получил спецификацию RFC 9824.

В частности, RFC 9824 вводит “мнимую” DNS-запись NXNAME (TYPE128) – это запись-сигнал об отсутствии в DNS-зоне запрошенного имени. Причина для введения такого сигнала в том, что упомянутый способ в принципе не позволяет отвечать со штатным для DNS статусом NXDOMAIN. Почему? Потому что весь смысл состоит в “подделывании” состава ответа, но, так сказать, с благими целями: при получении запроса о несуществующем имени, авторитативный сервер отвечает так, как если бы для этого имени нет DNS-записей в зоне: ANSWER: 0 и флаг NOERROR. В терминах DNS такой ответ называется NODATA – то есть, это корректный DNS-ответ без статуса ошибки, но пустой – не содержащий никаких ответных, – в блоке ANSWER, грубо говоря, – записей (естественно, это не означает, что DNS-ответ в целом не содержит записей: пуст только блок ANSWER, но записи в ответе есть, это дополнительные, “авторитативные” записи – SOA, NSEC и т.д.).

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

Для того, чтобы в новой схеме отличить ситуацию, когда действительно нет записей, от ситуации, когда нет имени, как раз и служит новая запись-сигнал NXNAME. Авторитативный сервер указывает NXNAME в составе полей NSEC-записи, если нет DNS-имени. NSEC – это запись, обозначающая “границу” зоны (в данном случае – фиктивную границу), NSEC нужна для того, чтобы было что подписывать, так как нельзя подписывать пустое значение. Технически, подписать-то можно, но такую подпись легко скопировать и применять к отсутствию любых записей в DNSSEC, то есть в безопасной DNS-зоне: это как раз пример того, что все пустые множества одинаковые, а окрашивать можно только пустые коробки, вот как в случае с NXNAME/NODATA и NXDOMAIN.

Здесь играет роль ещё одна нетривиальная особенность DNS, которую мало кто понимает. А именно: в DNS распространены ситуации, когда возникают заведомо пустые, но поименованные, фрагменты имени. Предположим, что есть имя a.b.c.example.com, для которого указана A-запись. Это имя находится в зоне example.com, но A-запись указана только для a.b.c. Как трактовать имя b.c.example.com (без a.)? Оно, вроде как, есть, потому что в DNS полное имя строится в форме иерархии лейблов, разделяемых точками. Но, не менее “вроде как”, этого имени и “нет”, потому что для него в принципе не указаны никакие записи: из “полных” имён тут будет только example.com и a.b.c.example.com. Для корректной обработки такого случая, в схеме, где NXDOMAIN-ответ невозможен, нужен сигнал, позволяющий отличить несуществование имени от несуществования записи для этого имени. Это и есть NXNAME.

Конечно, занимательно. Но, другое дело, что, с одной стороны, новый подход позволяет быстро, в онлайн-режиме генерировать подписанные DNS-ответы, удостоверяющие отсутствие запрошенной записи или отсутствие имени. С другой стороны, логика DNS очередной раз усложняется, а клиент, резолвер – должен подерживать обработку NXNAME, иначе для него разные пустые коробки склеиваются в одну (отсутствие записи склеивается с отсутствием имени).

Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.

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

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

Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог выпуска сертификатов, который лог становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.

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

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

Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.

И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).

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

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

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

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

То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.