OCSP stapling in Nginx >=1.3.7
Gena Makhomed
gmm на csdoc.com
Чт Сен 20 17:55:30 UTC 2018
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