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

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

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

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

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

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

Этот уровень приложений, как ни странно, очень технологичен. Но речь тут вовсе не про “используй фреймворк “Имярек”, чтобы лучше адаптировать агентов типа John Doe”. Нет. “Фреймворк и агенты” – это технологии, но не технологичность. Технологичность скрывается за процессом контроля над способом применения технологий. Если на примере инфраструктуры УЦ: сейчас кругом только и слышно, что про ACME и его использование – это про протокол автоматического заказа и получения TLS-сертификатов. Но реально ли речь всегда идёт о протоколе? Оказывается, нет. ACME – весьма заумный и развесистый протокол. Мало кто читал спецификацию, мало кто его понимает. Оказывается, что в большинстве случаев использовать хотят не протокол, а некий готовый продукт, популярную утилиту или библиотеку на основе ACME. Например, хотят не ACME, а чтобы работали certbot или acme.sh, а также и какой-нибудь ещё фреймворк. Вот эта зависимость – и есть технологичность, а не просто технологии.

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

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

Использование хеш-деревьев в TLS-инфраструктуре веба, в TLS-сертификатах, обусловлено переходом на постквантовые криптосистемы цифровой подписи. Тоже хороший пример. Возможно, что в некоторый момент ведущие разработчики браузеров скажут, что браузеры больше не считают стойкими и надёжными сертификаты, выпущенные без постквантовой криптосистемы, а соответствующие веб-сайты – будут отображаться “как небезопасные”. Сложно ли такое представить? Конечно нет. Это вполне логично – устаревшие технологии в какой-то момент оказываются слабыми, браузер должен их блокировать тоже – какие могут быть возражения? Такое уже несколько раз происходило, и с DSA, и с SHA-1, и с длительностью действия сертификатов, и так далее, и тому подобное.

Ещё раз подчеркну – хитрость в том, что, действительно, устаревшие криптосистемы теряют стойкость, это без всякого сарказма. А вот уже с длительностью действия сертификатов – есть разные точки зрения, как говорится. Но Google в браузере Chrome даже не собирается поддерживать постквантовые криптосистемы подписи сертификатов, кроме как в варианте с хеш-деревьями (MT-сертификаты). Так что токены доступа – станут токенами доступа, и эта роль не зависит от типа носителя.

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

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

Адрес записки: https://dxdt.blog/2026/06/14/18456/