Hello!

On Tue, Sep 11, 2018 at 10:00:05PM +0300, Gena Makhomed wrote:

> 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

Что, насколько я понимаю, предполагает out-of-band trust, и не
распространяется на ответы от собственно OCSP-сервиса CA. В
реальной жизни - это работать не будет.

В 4.2.2.2, описывающем поведение CA при подписи OCSP-ответов,
закрытый список из двух пунктов.

> > В обоих случаях для проверки 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'а?

Именно в "до доверенного root'а" и состоит проблема. Для проверки
подписи OCSP-ответа достаточно знать issuer'а - обычно это
промежуточный CA, и так или иначе лежит в цепочке на сервере (и
его так или иначе надо знать, чтобы сформировать OCSP-запрос).

Знать всю цепочку вплоть до root'а - серверу при этом не нужно.
Однако приходится, потому что в противном случае OpenSSL не может
проверить OCSP-ответ.

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

Потому что это не требование - а, напротив, отсутствие требования
признавать что-то, что подписано так, что проверка OCSP-ответа с
помощью только issuer'а оказывается невозможна. В частности, в
пункте 4.2.2.2 вслед за "MUST be issued directly" сказано так:

Note: For backwards compatibility with RFC 2560 [RFC2560], it is not
prohibited to issue a certificate for an Authorized Responder
using a different issuing key than the key used to issue the
certificate being checked for revocation. However, such a
practice is strongly discouraged, since clients are not
required to recognize a responder with such a certificate as an
Authorized Responder.

То есть если OCSP-ответ не подписан напрямую issuer'ом (и тогда
проверка подписи тривиальна, response -> issuer) или выпущенным им
сертификатом (и тогда проверка подписи чуть сложнее, но тоже
проста, response -> responder -> 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

Какой-либо фактической информации, позволяющей сравнить случаи
использования OCSP stapling и его не использования, эта статья не
содержит.

А о том, что ребята в CloudFlare обладают выдающимися моральными
качествами и способны написать статью о том, как они включили
разработанную мной функциональность в nginx'е без единой ссылки на
меня и nginx - я и так в курсе, спасибо.

> > Про verify - тоже есть нюансы. Дискуссия, если я её правильно
> > понял, как раз о том, что включать verify обходится дороже с
> > административной точки зрения, чем хотелось бы. При этом плюсы -
> > призрачны, ибо защищают от атак, которых на практике не бывает
> > (а если бы они были - браузеры бы давно исправились).
>
> В начале дискуссии вопрос был о том, почему для того чтобы директива
> ssl_stapling_verify on; нормально работала необходимо также прописывать
> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
> если содержимое файла chain.pem можно получить из файла fullchain.pem
> выбросив оттуда первый сертификат, который является сертификатом сайта?

И ответ на этот вопрос - потому что интерфейс проверки сертификатов
кривой, и требует массы дополнительных приседаний, чтобы работать.
Именно поэтому по умолчанию используется ssl_stapling_verify off.

Кроме того, если у вас в ssl_certificate указана полная цепочка,
включая сертификат root CA, то это неправильно. Root-сертификат у
клиентов и так есть, отправлять клиентам его - бессмысленная трата
ресурсов, соответственно и включать его в цепочку в
ssl_certificate - не надо.

Если же root-сертификата в цепочке нет, то получить из
ssl_certificate полную цепочку, включая root, по очевидным
причинам не получится, и ssl_stapling_verify работать не будет.

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

Директива ssl_trusted_certificate появилась фактически в рамках
работы над OCSP stapling, так что "как раньше" это странное
утверждение.

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

Это откровенное маркетинговое передёргивание, не учитывающее
никаких других эффектов от OCSP stapling'а, кроме собственно
"улучшений". Не говоря уже о том, что:

а) Цифры в исходном посте Mike Belshe - это не статистика, а
конкретный trial с конкретным сервером и конкретным CA, и всё это
в мобильной сети.

б) Ребята в CloudFlare насчитали 30%, сложив время всех операций,
относящихся к OCSP. Меж тем, там будет максимум 16% даже без
учёта увеличения времени handshake'а за счёт OCSP-ответов, так как
OCSP stapling работает только для конечного сертификата, а цифры
приводятся с учётом проверки отзыва промежуточного CA.

Не надо на это вестись.

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