Hello!

On Sat, Sep 15, 2018 at 02:35:35PM +0300, Gena Makhomed wrote:

> On 12.09.2018 17:36, Maxim Dounin wrote:
>
> >>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять
> >>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного
> >>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью
> >>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет.
>
> Задал вопрос по этому поводу в списке рассылки openssl-users:
> https://mta.openssl.org/pipermail/openssl-users/2018-September/008795.html
> - пока что мне там никто ничего так и не ответил.
>
> >>> В зависимости от того, каким сертификатом подписан OCSP-ответ -
> >>> этого может быть достаточно или нет. RFC 6960 допускает два
> >>> варианта подписи в OCSP-ответах:
>
> >>> - issuer подписывает OCSP-ответ сам; или
> >>> - issuer выпускает сертификат, которым подписываются OCSP-ответы
> >>> (и этот сертификат включается в OCSP-ответ).
>
> >>> В обоих случаях для проверки OCSP-ответа достаточно знать
> >>> issuer'а, однако второй случай в OpenSSL не работает (впрочем, я
> >>> давно не порверял; но если верить "документации", в этом месте
> >>> ничего не зименилось). При этом по понятным причинам мало кто
> >>> использует собственно CA для подписи OCSP-ответов, соответственно
> >>> не работает это приблизительно всегда.
>
> Проверил второй случай, openssl-1.0.2k из CentOS 7.5 все работает:
>
> 1. Получаю сертификат сервера (0) и сертификат issuer'а (1):
> openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | less
>
> Сертификат сервера сохраняю в файл www.godaddy.com-cert.pem
> а сертификат issuer'а - в файл www.godaddy.com-issuer.pem
>
> 2. Узнаю OCSP URI, это http://ocsp.godaddy.com/
> openssl x509 -text -noout -in www.godaddy.com-cert.pem | less
>
> 3. Делаю запрос на получение OCSP ответа от этого сервера:
> openssl ocsp -verify_other www.godaddy.com-issuer.pem -issuer
> www.godaddy.com-issuer.pem -cert www.godaddy.com-cert.pem -text -url
> http://ocsp.godaddy.com/ -header "Host" "ocsp.godaddy.com" | less
>
> Из ответа видно, что для подписи используется отдельный сертификат
> Go Daddy Validation Authority - G2, при этом "Response verify OK",
> то есть OpenSSL может проверить ответ сервера и в этом случае.
>
> Если убрать параметр '-verify_other www.godaddy.com-issuer.pem'
> тогда возвращается сообщение про ошибку:
>
> Response Verify Failure
> 140345419933584:error:27069065:OCSP
> routines:OCSP_basic_verify:certificate verify
> error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
>
> Получается, что OpenSSL уже очень давно умеет проверять
> OCSP-ответ с помощью одного только сертификата issuer'а?

Получается, что в CentOS 7.5 есть bundle с доверенными корневыми
сертификатами, который используется openssl по умолчанию. Если
его отключить - указав параметры -CAfile и -CApath явно - то
валидация сломается.

> >>>> Насколько я понял из предыдущего обсуждения, нет разумных причин,
> >>>> чтобы выключать использование OCSP stapling и ocsp_stapling_verify.
> >>>>
> >>>> И вместе с тем, есть причины, чтобы их включать:
> >>>> OCSP stapling - сайт у клиентов будет открываться быстрее.
> >>>> ocsp_stapling_verify - не будет проблем с неразумными браузерами.
> >>
> >>> Про "быстрее" - есть нюансы. В частности, OCSP-ответ отправляется
> >>> клиенту, пытающемуся использовать OCSP stapling, в каждом
> >>> SSL handshake'е (а это местами может быть больно с точки зрения latency, не
> >>> говоря уже про трафик), в то время как в значительной части
> >>> случаев он клиенту на самом деле не нужен (например, уже есть в
> >>> кэше).
>
> Почему это может быть больно с точки зрения latency? Ведь nginx держит
> OCSP-ответ в своей памяти и отдает его клиенту практически мгновенно.
> Этот ответ как правило валиден от 24 часов до 7 или даже 14 дней.
>
> Трафик - это дополнительный килобайт, максимум два килобайта.
> Разве это много? Страница сайта весит от сотен килобайт
> до нескольких мегабайт, и 1-2 килобайта роли не играют.

Дополнительная пара килобайт в начале соедениния - это
потенциальный выход за пределы исходного окна, и соответственно
лишний RTT на соединение.

С получившим сейчас достаточно широкое распространение initcwnd10
(rfc6928, окно до 14k) - скорее всего плохо не будет (но тоже
вопрос, какая цепочка сертификатов при этом стоит), а если
используется более традиционный rfc3390 с окном до 4 килобайт -
как раз из-за stapling'а нарваться на лишний round-trip
элементарно.

Что до трафика, то всё зависит как раз от того, какой в данном
конкретном случае средний трафик передаётся по соединению. И
далеко не везде это сотни килобайт.

> Если OCSP-статус сертификата клиенту не нужен,
> зачем же в таком случае клиент его постоянно запрашивает?
>
> Это же клиент решает, получать ему OCSP-статус сертификата или нет.

Клиент не может знать, нужен ему статус или нет. Более того - он
даже не может знать, какой сертификат ему вернут. Соответственно
если он использует stapling - то в любом полном handshake'е
вынужден получать и stapling тоже.

[...]

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

К сожалению, это работает не так. Точнее - так это не работает.
Всё что можно передать - nginx передаёт, но этого недостаточно,
если OCSP-ответы подписаны с использованием промежуточного
сертификата.

> > Кроме того, если у вас в ssl_certificate указана полная цепочка,
> > включая сертификат root CA, то это неправильно. Root-сертификат у
> > клиентов и так есть, отправлять клиентам его - бессмысленная трата
> > ресурсов, соответственно и включать его в цепочку в
> > ssl_certificate - не надо.
>
> У меня сертификат получен с помощью certbot,
> "Let’s Encrypt Authority X3" - это промежуточный сертификат.
> Он подписан с помощью "DST Root CA X3", подробности здесь:
> https://letsencrypt.org/certificates/
>
> В конфиге nginx прописано
>
> ssl_stapling on;
> ssl_stapling_verify on;
> resolver 127.0.0.1;
>
> ssl_certificate /etc/letsencrypt/live/.../fullchain.pem;
> ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem;
>
> Директива ssl_trusted_certificate вообще нигде в конфиге не указана,
> при этом - nginx не пишет в лог никаких ошибок верификации сертификата.

Потому что letsencrypt - подписывает OCSP-ответы непосредственно
issuer'ом, не используя промежуточный сертфикат. Соответственно
для него - ssl_stapling_verify работает без дополнительных
приседаний, хватает сертифката issuer'а, который nginx достаёт из
цепочки ssl_certificate.

К сожалению, это далеко не всегда так. И к ещё большему сожалению -
никто не гарантирует, что в один прекрасный момент это не
перестанет быть так и для letsencrypt тоже.

[...]

> Кстати, пользователи жалуются, что есть BUG в nginx,
> связанный с сертификатами с флагом "OCSP Must Staple":
> https://blog.crashed.org/nginx-stapling-busted/

Потому что "Must Staple" - это попытка превратить OCSP stapling из
механизма оптимизации в обязательный механизм, аналогичный
короткоживущим сертификатам. Не сюрприз, что так не работает -
требования совершенно разные.

Любители Must Staple общаются в траке в двух тикетах:

https://trac.nginx.org/nginx/ticket/812
https://trac.nginx.org/nginx/ticket/990

Пока что они делают это с нулевым полезным выходом.

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