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/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru