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 - не будет проблем с неразумными браузерами.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru