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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
