Welcome! Log In Create A New Profile

Advanced

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed
September 15, 2018 07:36AM
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'а?

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

Почему это может быть больно с точки зрения latency? Ведь nginx держит
OCSP-ответ в своей памяти и отдает его клиенту практически мгновенно.
Этот ответ как правило валиден от 24 часов до 7 или даже 14 дней.

Трафик - это дополнительный килобайт, максимум два килобайта.
Разве это много? Страница сайта весит от сотен килобайт
до нескольких мегабайт, и 1-2 килобайта роли не играют.

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

Это же клиент решает, получать ему OCSP-статус сертификата или нет.

Вот ответ сервера, если OCSP-статус не запрашивать:

openssl s_client -showcerts -connect www.godaddy.com:443 < /dev/null | less

А вот ответ сервера, если OCSP-статус запрашивать:

openssl s_client -showcerts -status -connect www.godaddy.com:443 <
/dev/null | less

Если глупый клиент постоянно запрашивает OCSP-статус сертификата,
даже в том случае если ему этот статус уже известен и не нужен
- это наверное не проблемы сервера, а проблемы самого клиента.
(И исправлять эту проблему надо на клиенте а не на сервере)

>> Открытие сайта по HTTPS без OCSP Stapling подразумевает,
>> что браузер сам будет проверять не отозван ли сертификат сервера.
>> Клиент в это время будет сидеть перед монитором и ждать открытия сайта.

> Или не будет - см. пример в скобках.

Обычно веб-мастера стараются максимально ускорить первое открытие сайта
клиентом. Потому что если сайт будет открываться долго, например, 5 или
10 секунд - пользователь этого может просто не дождаться и уйти.

При первом открытии сайта - OCSP-ответа точно нет в кэше клиента.

>>> Про 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 - это не выглядит очень сложным.

> Кроме того, если у вас в 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 не пишет в лог никаких ошибок верификации сертификата.

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

Почему же в таком случае nginx не пишет в лог никаких ошибок?
Версия 1.15.3, пакет из официального репозитория nginx.org

>>> Единственное несомненное преимущество OCSP stapling'а
>>> - это меньшая нагрузка на инфраструктуру CA

Let’s Encrypt дает мне SSL-сертификаты полностью бесплатно,
с моей стороны нормально будет в ответ уменьшить нагрузку
на их сервера, включив OCSP stapling для всех сайтов.

Если же я выключу OCSP stapling, тогда я буду в чем-то
похож на персонажа басни Крылова "Свинья под дубом".

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

Они же это делают не для того, чтобы навредить своим клиентам,
а наоборот, чтобы сайты их клиентов открывались еще быстрее?

P.S.

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

--
Best regards,
Gena

_______________________________________________
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: 126
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready