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

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

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

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

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

Тут можно возразить, что браузер и так имеет возможность заблокировать любой сайт, просто по имени хоста сервера, по URL, ещё как-то. Получается, ничего нового, в плане возможностей, для пользователя и браузера не появляется. Это не совсем так.

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

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

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

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

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

Адрес записки: https://dxdt.ru/2025/12/03/16628/