OCSP stapling: что это и почему он не обязателен

Проблема обычного OCSP

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

Если респондер медленный или недоступный, браузеры либо пропускают проверку, либо блокируют сайт — в зависимости от клиента. Ни то, ни другое не хорошо.

Что меняет stapling

Со stapling сервер сам получает подписанный OCSP-ответ, кэширует его и прикрепляет к TLS-рукопожатию. Браузер получает ответ об отзыве, ни к кому не обращаясь: без лишнего кругового обмена и без утечки.

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

Включение и проверка

В nginx для stapling нужны resolver и файл цепочки, иначе он молча ничего не делает. В Apache директива кэша должна быть на уровне сервера. После перезагрузки проверьте снаружи — присутствующая, но неработающая строка конфигурации выглядит точно так же, как отсутствующая.

# nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

# verify from outside — look for a stapled response, not just "OCSP response: none"
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A3 "OCSP Response Status"

Почему для A+ он не требуется

Stapling — улучшение приватности и задержки, а не стойкости протокола. Сервер без stapling не становится «менее безопасным» так, как сервер с TLS 1.0. CertH считает его положительным сигналом в разделе здоровья конфигурации, но не требует для высшей оценки.

Тем не менее это один из самых дешёвых выигрышей: две строки конфигурации, нулевое влияние на клиентов и измеримый выигрыш в приватности для каждого посетителя.

FAQ