Gena Makhomed
September 19, 2018 10:42PM
On 20.09.2018 3:06, Maxim Dounin wrote:

>> Правильной была бы цель "сделать обязательной проверку отзыва"
>> без каких-либо дополнительных условий?

> Именно так. Потому что мешать в одну кучу требование о проверке
> отзыва сертфиката и технические аспекты одного из вариантов этой
> проверки - это плохой путь.

>> Правильным решением в таком случае был бы флаг в сертификате
>> "обязательно проверять отзыв сертификата", так что если веб-сервер
>> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер
>> использует его, а если веб-сервер ничего не прислал, тогда браузер
>> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ?
>> И только если браузер не смог получить OCSP-ответ, только в этом случае
>> запрещать клиенту доступ к сайту с таким флагом в сертификате?

> И это было бы логично: именно так сейчас браузеры, использующие
> OCSP, и работают, с той лишь разницей, что по результатам
> неудачной проверки доступ - не запрещают.

Может быть еще не поздно предложить RFC в котором будет
описан такой флаг "сделать обязательной проверку отзыва" ?

>> Такое решение задачи наверное было бы наиболее удобным для создателей
>> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA,

> Не увеличило бы. Потому что по факту - OCSP сейчас и так включён
> по умолчанию во всех браузерах, его использующих.

Если не увеличило бы, почему же тогда представители CA были против?

========================================

On 18.09.2018 22:09, Maxim Dounin wrote:

> Было предложено сделать отдельный флаг в сертификатах, требующий
> hard fail для конкретного сертификата. Но это в свою очередь не
> понравилось представителям CA, так как они справедливо полагали,
> что подобные сертификаты могут создать серьёзную нагрузку на
> OCSP-сервера (как, впрочем, и на CRL Distribution Points, но
> браузеры сейчас фактически не пользуются CRL в чистом виде). И
> "must staple" получился как некоторый итог этого столкновения
> интересов.

========================================

>>> В тот момент, когда от клиента пришло соединение с запросом
>>> certificate status и OpenSSL'ем был вызван соответствующий
>>> callback - у nginx'а нет возможности как-либо отложить обработку
>>> этого соединения.
>>>
>>> Соответственно либо к этому моменту у nginx'а уже есть
>>> соответствующий OCSP-ответ - и тогда он может его отправить
>>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не
>>> может его отправить, а максимум что может - это инициировать
>>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих
>>> клиентов.

>> У nginx есть отдельный процесс cache manager, который управляет кэшем
>> независимо от рабочих процессов nginx, может быть имеет смысл также
>> сделать ocsp cache manager, который будет заниматься получением
>> и кэшированием OCSP-ответов для всех присутствующих сертификатов?

> Можно сделать много всего. Но это не избавляет от ситуации, когда
> соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого
> OCSP-ответа - ещё нет.

Избавляет полностью, если OCSP responder отвечает на запросы.

Когда в конфиг добавили новый сертификат и сделали reload -
сначала ocsp cache manager убеждается, что у него есть актуальные
OCSP-ответы для всех "Must Staple" сертификатов и только после этого
применяется новая конфигурация для всех рабочих процессов nginx'а.

Когда в конфиг добавили новый сертификат и запустили nginx -
сначала запускается ocsp cache manager, убеждается, что у него есть
актуальные OCSP-ответы для всех "Must Staple" сертификатов и только
после этого запускаются рабочие процессы nginx'а.

Когда в процессе работы nginx'а OCSP responder не доступен более
чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация
и в таком случае nginx просто закрывает соединение с клиентом
для всех соединений с "Must Staple" сертификатами до тех пор,
пока актуальный OCSP-ответ не будет получен. Это лучше, чем
возвращать клиенту "Must Staple" сертификат без OCSP-ответа.

>>> Эту проблему можно столь же успешно решить, просто не пытаясь
>>> включать "ssl_prefer_server_ciphers". Попытки же изобретать
>>> сложную логику - "здесь играем, здесь не играем, здесь рыбу
>>> заворачивали" - выглядят, скажем мягко, странно.

>> Эта сложная логика уже изобретена и встроена в OpenSSL,
>> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.
>>
>> Получается очень красивое решение, так что и Forward Secrecy
>> можно получить с большинством браузеров и мобильные клиенты
>> будут использовать наиболее эффективный для них шифр ChaCha20.

> Это что угодно, но только не красивое решение. Люди потратили
> массу сил и времени на изобретение сложной логики (и теперь хотят,
> чтобы разработчики nginx'а и все пользователи nginx'а -
> присоединились к процессу, потому что встроить эту логику в
> существующий механизм выбора приоритета шифров - не осилили).
> И всё ради того, чтобы насильно обеспечить Forward Secrecy людям,
> сознательно забившим на обновление софта.

Не только. Директива ssl_prefer_server_ciphers применяется
и в тех случаях, когда в каком-то шифре находят уязвимость,
тогда этот шифр с помощью серверных приоритетов ставится
на последнее место. Совсем выключить нельзя, потому что
некоторые клиенты не умеют ничего другого кроме этого шифра.
Такое уже было, например, когда нашли уязвимость в RC4.
Или когда до того, наоборот, ставили RC4 на первое место,
чтобы защититься от уязвимости в браузерах по имени BEAST.

В такой ситуации все пользователи nginx'а будут поставлены
перед выбором: или защитить клиентов от уязвимости в шифре
но при этом быстро съедать батарею у мобильных пользователей
или экономить батарею у мобильных пользователей но иметь
включенным и выбираемым частью клиентов уязвимый шифр.

Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA
через директиву конфигурации nginx - это бы упростило жизнь,
тогда можно и уязвимый шифр выключить и батарею экономить.

--
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: 112
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