On 11.09.2018 18:59, Maxim Dounin wrote:

>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять
>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного
>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью
>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет.

[...]

>> 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-ответ).

На самом деле - там три варианта, вот еще третий:

- a Trusted Responder whose public key is trusted by the requestor

Подробности здесь: https://tools.ietf.org/html/rfc6960#section-2.2

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

В RFC 6960 написано по поводу сертификата из второго случая:

: This certificate MUST be issued directly
: by the CA that is identified in the request.

https://tools.ietf.org/html/rfc6960#section-4.2.2.2

Как это может не работать в OpenSSL, если сертификат, которым
подписываются OCSP-ответы является валидным и проверка идет
полной цепочкой сертификатов вплоть до доверенного root'а?

Кстати, мне так и не удалось найти в стандарте RFC 6960 требования
проверять OCSP-ответ с помощью одного только сертификата issuer'а.

>> 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, не
> говоря уже про трафик), в то время как в значительной части
> случаев он клиенту на самом деле не нужен (например, уже есть в
> кэше).

Открытие сайта по HTTPS без OCSP Stapling подразумевает,
что браузер сам будет проверять не отозван ли сертификат сервера.
Клиент в это время будет сидеть перед монитором и ждать открытия сайта.

https://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/
OCSP Stapling: How CloudFlare Just Made SSL 30% Faster

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

В начале дискуссии вопрос был о том, почему для того чтобы директива
ssl_stapling_verify on; нормально работала необходимо также прописывать
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
если содержимое файла chain.pem можно получить из файла fullchain.pem
выбросив оттуда первый сертификат, который является сертификатом сайта?

Кроме необходимости прописывать совсем лишние директивы в конфиге
есть и более серьезная проблема - директива ssl_trusted_certificate
сейчас исполняет две совершенно различные роли вместо одной, как раньше.

> Единственное несомненное преимущество OCSP stapling'а - это
> меньшая нагрузка на инфраструктуру CA
И на 30% более быстрое открытие сайта клиентом,
если на сервере используется OCSP stapling.

P.S.

Сегодня вышел релиз OpenSSL 1.1.1 с поддержкой TLSv1.3
https://www.openssl.org/blog/blog/2018/09/11/release111/

--
Best regards,
Gena

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