On 20.09.2018 16:01, Maxim Dounin wrote:

>>>> У 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-ответа.

> О чём и речь. Во всей этой конструкции - описано множество вещей,
> которые надо программировать, чтобы "must staple" хоть как-то
> заработал. И вещей, которые надо делать на старте nginx'а -
> просто для того, чтобы начать работать. И при этом нет сколь-либо
> разумного решения для ситуации, когда OCSP responder по каким-то
> причинам оказывается недоступен.

Срок жизни OCSP-ответов - самое меньшее что я видел, это 36 часов,
самое большее - это 7 суток. Предлагается не ждать полного истечения
срока жизни OCSP-ответа, а получать новый OCSP-ответ, когда прошло
уже 50% времени жизни текущего OCSP-ответа. Так что для получения
нового OCSP-ответа будет от 18 часов до 3.5 суток, это ведь много.

При старте nginx'а - в 99.999% случаев все необходимые OCSP-ответы
будут прочитаны ocsp cache manager из файловой системы, из кэша.
Так что задержка при старте nginx будет практически нулевой.

> Закрывать соединения - это плохой, негодный подход.

Тогда у nginx остается всего один вариант
- отправлять клиенту сертификат без OCSP-ответа.

Но если OCSP responder работает нормально и оказался не доступен
на небольшой промежуток времени, например, всего на несколько
часов - такой проблемы не будет.

> При этом всего этого можно было бы легко избежать, не пытаясь
> вводить "must staple" вместо требования проверки отзыва.

Автор RFC 7633 - представитель CA, ему далеки проблемы веб-серверов.

>>>> Эта сложная логика уже изобретена и встроена в OpenSSL,
>>>> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.

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

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

Директива для включения SSL_OP_PRIORITIZE_CHACHA никому бы не помешала.
Кто не хочет участвовать в процессе - просто не трогают ее и оставляют
по-дефолту выключенной, а кто хочет участвовать - включает и радуется.

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

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

> Я не спорю с тем, что соответствующая возможность - может
> оказаться полезной в каких-то ситуациях.

> Мне тут в первую очередь печально, что со стороны OpenSSL
> получилось очередной ad-hoc решение, требующее отдельной ручки -
> вместо, например, групп шифров с одинаковым приоритетом в строке
> спецификации шифров.

А как в nginx в строке спецификации шифров ssl_ciphers
можно задать группу шифров с одинаковым приоритетом?

> Ну и равно печально, что люди не понимают, что включать
> ssl_prefer_server_ciphers в отсутствии серьёзных проблем,
> которые нужно решать на стороне сервера - не стоит.

Включать ssl_prefer_server_ciphers - такое решение рекомендует
всем людям и https://www.ssllabs.com/ssltest/ и Mozilla в своем
https://mozilla.github.io/server-side-tls/ssl-config-generator/
и много кто и где еще.

--
Best regards,
Gena

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