OCSP stapling in Nginx >=1.3.7

[Maxim Dounin]

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/