OCSP stapling in Nginx >=1.3.7

Maxim Dounin mdounin на mdounin.ru
Вт Сен 18 19:09:07 UTC 2018


Hello!

On Tue, Sep 18, 2018 at 10:49:26PM +0500, Илья Шипицин wrote:

> вт, 18 сент. 2018 г. в 22:28, Maxim Dounin <mdounin at mdounin.ru>:
> 
> > Hello!
> >
> > On Tue, Sep 18, 2018 at 09:18:52PM +0500, Илья Шипицин wrote:
> >
> > > вт, 18 сент. 2018 г. в 19:01, Gena Makhomed <gmm at csdoc.com>:
> >
> > [...]
> >
> > > > То есть цель у флага OCSP Must-Staple наверное та же самая,
> > > > что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA.
> > >
> > >  цель у этого флага непонятна никому. есть ощущение, что (как и многие
> > > аспекты TLS/SSL) это просто не очень продуманный дизайн.
> >
> > Цель не секрет же - сделать обязательную проверку отзыва
> > сертификата.  Против явного флага "обязательно проверять отзыв"
> > активно возражали представители CA - справедливо полагая, что им
> > от таких сертификатов прилетит нагрузки на OCSP-сервера - в
> > результате получилось вот такое вот.
> >
> 
> собственно, через CDP/CRL проверка не менее "обязательная"
> тут вопрос в том, что они хотели сделать обязательной именно OCSP проверку
> 
> подозреваю, что на клиенте можно любую отключить (CDP/CRL точно,  OCSP не
> смотрел еще как)

Проблема в том, что сейчас (и всегда) проверка отзыва - не является 
обязательной.  И, более того, количество случайных ошибок при 
проверках отзыва сертификатов таково, что даже если браузер 
проверяет отзыв сертификата, то в случае ошибки - всё равно даёт 
доступ к сайту (aka "soft fail").

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

При этом идея "давайте всегда проверять отзыв, и если не смогли 
этого сделать - возвращать клиенту ошибку" (aka "hard fail" для 
всех по умолчанию) была не близка браузерам, они логично полагали, 
что будет много случайных ошибок из-за недоступности CDP и/или 
OCSP-серверов, и пользователи не будут счастливы.

Было предложено сделать отдельный флаг в сертификатах, требующий 
hard fail для конкретного сертификата.  Но это в свою очередь не 
понравилось представителям CA, так как они справедливо полагали, 
что подобные сертификаты могут создать серьёзную нагрузку на 
OCSP-сервера (как, впрочем, и на CRL Distribution Points, но 
браузеры сейчас фактически не пользуются CRL в чистом виде).  И 
"must staple" получился как некоторый итог этого столкновения 
интересов.

По крайней мере как-то так историю появления "must staple" помню 
я, благо как раз в это время был подписан на cabforum mailing list 
и наблюдал процесс в развитии.  Могу, впрочем, врать в деталях (и 
не только в деталях) - это было давно, да и моё личное мнение о 
итоге - влияет на восприятие.

IMHO, итог получился так себе - получили ещё одну неработающую 
технологию вместо логичного флага о том, как следует относиться к 
ошибкам проверки отзыва сертификата.

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

Впрочем, возможно на подобное закладываться и не надо, а 
достаточно улучшить получение и кэширование OCSP-ответов, чтобы 
минимизировать шансы возникновения подобных проблем, и с 
практической точки зрения этого будет достаточно.

-- 
Maxim Dounin
http://mdounin.ru/


Подробная информация о списке рассылки nginx-ru