OCSP stapling in Nginx >=1.3.7

[Илья Шипицин]

вт, 11 сент. 2018 г. в 19:40, Gena Makhomed <gmm на csdoc.com>:

> 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?
>
> >> Но даже если вдруг новые версии 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 сломался у Lets Encrypt, помнится, проблемы были у тех, у кого
они не должны были быть

https://community.letsencrypt.org/t/what-if-lets-encrypt-goes-down-ocsp-stapling/22369/2



>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180911/51934121/attachment.html>