Welcome! Log In Create A New Profile

Advanced

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin
September 16, 2018 07:38PM
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
Subject Author Posted

OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 06, 2018 11:28AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 10, 2018 09:06AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 10, 2018 03:40PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 10, 2018 04:24PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 10, 2018 05:01PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 03:08AM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 10, 2018 04:52PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 10, 2018 11:22PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 04:12AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 04:16AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 11, 2018 08:40AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 10:42AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 11:06AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 11, 2018 12:00PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 03:00PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 12, 2018 10:38AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 15, 2018 07:36AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 16, 2018 07:38PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 17, 2018 09:06AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 18, 2018 10:02AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 12:20PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 01:30PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 01:50PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 03:10PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 01:04PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 18, 2018 04:10PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 06:54PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 19, 2018 07:46PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 18, 2018 05:28PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 06:00PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 03:26PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 19, 2018 03:54PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 02:58PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 06:32PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 08:08PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 10:42PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 20, 2018 02:32AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 20, 2018 09:02AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 20, 2018 09:52AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 20, 2018 01:56PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 20, 2018 07:48PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 21, 2018 12:42PM

How to Improve SEO with HTTPS and NGINX

Gena Makhomed September 15, 2018 11:22AM

Re: How to Improve SEO with HTTPS and NGINX

Maxim Dounin September 16, 2018 07:44PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 188
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready