OCSP stapling in Nginx >=1.3.7

[Maxim Dounin]

Hello!

On Tue, Sep 11, 2018 at 05:40:19PM +0300, Gena Makhomed wrote:

> On 11.09.2018 15:38, Maxim Dounin wrote:
> 
> >>> Лучше всего - сделать так, чтобы OpenSSL научился проверять
> >>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного
> >>> root'а, а ровно так, как и должно быть по стандарту - с помощью
> >>> одного только сертификата issuer'а.  Тогда проблема исчезнет.
> 
> >> А разработчики OpenSSL разве знают об этой проблеме?
> >> На гитхабе https://github.com/openssl/openssl/issues
> >> я не нашел issue в которой бы описывалась эта проблема.
> 
> > О проблеме писалось ещё до того, как OpenSSL переехал на github,
> > и вроде бы даже был тикет на rt.openssl.org про это.
> > Но я не следил, и не планирую.
> 
> > Этим летом в кои-то веки документировали саму функцию
> > OCSP_basic_verify(), используемую для проверки OCSP-ответов.  И
> > если самого факта недостаточно для понимания проблемы, то стоит
> > прочитать эту самую документацию, она доставляет.
> 
> Почитал документацию
> https://www.openssl.org/docs/manmaster/man3/OCSP_basic_verify.html
> там говорится о флаге OCSP_TRUSTOTHER, смысл примерно такой:
> 
> : ... or if the signer certificate was found in certs and
> : the flags contain OCSP_TRUSTOTHER. Otherwise the function
> : continues by validating the signer certificate.
> 
> О том же написано и в CHANGELOG:
> 
>    *) New OCSP verify flag OCSP_TRUSTOTHER. When set the "other"
>       certificates passed by the function are trusted implicitly.
>       If any of them signed the response then it is assumed
>       to be valid and is not verified.
> 
> Насколько я понимаю, это и есть та самая проверка с помощью
> одного только сертификата issuer'а, о которой Вы говорите?
> 
> Если это то, что надо, то сейчас уже ничто не мешает сделать
> в nginx директиву ocsp_stapling_verify включенной по-умолчанию?
> И для ее работы не нужно будет прописывать ssl_trusted_certificate?

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

- issuer подписывает OCSP-ответ сам; или
- issuer выпускает сертификат, которым подписываются OCSP-ответы 
  (и этот сертификат включается в OCSP-ответ).

В обоих случаях для проверки OCSP-ответа достаточно знать 
issuer'а, однако второй случай в OpenSSL не работает (впрочем, я 
давно не порверял; но если верить "документации", в этом месте 
ничего не зименилось).  При этом по понятным причинам мало кто 
использует собственно CA для подписи OCSP-ответов, соответственно 
не работает это приблизительно всегда.

> >> Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы
> >> с помощью одного только сертификата issuer'а - проблема не исчезнет.
> 
> >> Потому что останется огромное количество операционных систем,
> >> в которых будет установлена старая версия OpenSSL, например,
> >> CentOS/RHEL. Новые версии этой системы выходят очень редко.
> 
> >> И потребуется как минимум 5-10 лет, прежде чем новые версии
> >> OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов.
> 
> > Никто не мешает не использовать OCSP stapling.  Либо же не
> > использовать ocsp_stapling_verify.  При разумном поведении
> > браузеров - от отсутствия проверки на стороне nginx'а проблем быть
> > не должно.  Если же браузеры по какой-то причине предпочитают
> > вести себя неразумно - что ж, это их выбор.
> 
> ocsp_stapling_verify в nginx можно без проблем использовать
> и прямо сейчас, только для этого надо прописать дополнительно
> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
> 
> Насколько я понял из предыдущего обсуждения, нет разумных причин,
> чтобы выключать использование OCSP stapling и ocsp_stapling_verify.
> 
> И вместе с тем, есть причины, чтобы их включать:
> OCSP stapling - сайт у клиентов будет открываться быстрее.
> ocsp_stapling_verify - не будет проблем с неразумными браузерами.

Про "быстрее" - есть нюансы.  В частности, OCSP-ответ отправляется 
клиенту, пытающемуся использовать OCSP stapling, в каждом 
SSL handshake'е (а это местами может быть больно с точки зрения latency, не 
говоря уже про трафик), в то время как в значительной части 
случаев он клиенту на самом деле не нужен (например, уже есть в 
кэше).

Про verify - тоже есть нюансы.  Дискуссия, если я её правильно 
понял, как раз о том, что включать verify обходится дороже с 
административной точки зрения, чем хотелось бы.  При этом плюсы - 
призрачны, ибо защищают от атак, которых на практике не бывает 
(а если бы они были - браузеры бы давно исправились).

Единственное несомненное преимущество OCSP stapling'а - это 
меньшая нагрузка на инфраструктуру CA.

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