On 18.09.2018 20:03, Maxim Dounin wrote:

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

>>> Потому что "Must Staple" - это попытка превратить OCSP stapling
>>> из механизма оптимизации в обязательный механизм, аналогичный
>>> короткоживущим сертификатам. Не сюрприз, что так не работает -
>>> требования совершенно разные.

>> RFC 7633 был создан сотрудником Comodo, в RFC он пишет,
>> что цель RFC - "prevents a denial-of-service attack".
>>
>> Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder
>> - клиенты не смогут отличить отозванный сертификат от действительного.
>>
>> При массовом внедрении флага OCSP Must-Staple в сертификаты
>> - делать DDoS-атаки на OCSP responder не будет иметь смысла.
>>
>> То есть цель у флага OCSP Must-Staple наверное та же самая,
>> что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA.

> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать
> обязательной проверку отзыва, не нагружая дополнительно
> инфраструктуру CA.
>
> Проблема в том, что нельзя просто так взять механизм оптимизации и
> сделать из него механизм контроля, это две разные задачи, которые
> надо решать по-разному.

Если задача стоит "сделать обязательной проверку отзыва,
не нагружая дополнительно инфраструктуру CA" - как же можно
решить эту задачу другими методами, без флага Must Staple?

Ведь флаг "обязательно проверять отзыв через OCSP" создаст
очень большую нагрузку на CA - это будет хуже чем Must Staple.
Тем более, что сейчас Google Chrome OCSP вообще не использует.

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

>>> Любители Must Staple общаются в траке в двух тикетах:
>>>
>>> https://trac.nginx.org/nginx/ticket/812
>>> https://trac.nginx.org/nginx/ticket/990
>>>
>>> Пока что они делают это с нулевым полезным выходом.

>> Они в основном там просят сделать возможным указывать в конфиге
>> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов.
>>
>> Но есть ведь и другие способы решения этой проблемы, например,
>> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того,
>> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто
>> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер.

> Проблема для начала в том, что в OpenSSL нет возможности подождать
> получения OCSP-ответа, не блокируя рабочий процесс nginx'а.

Насколько я понимаю из исходников, nginx делает запрос к OCSP
серверу самостоятельно, не блокируя рабочий процесс nginx'а.

Очень похожий функционал запроса с "ожиданием" уже реализован в nginx,
в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется.

> Я не считаю использование "ssl_prefer_server_ciphers on"
> правильным приблизительно нигде, кроме ситуаций, когда автор
> конфигурации чётко понимает, чего он хочет добиться, и регулярно
> занимается анализом и пересмотром списка используемых шифров.
>
> И даже в этом случае - его использование подчас выходит боком, как
> например с выбором AES vs. ChaCha20:
>
> https://trac.nginx.org/nginx/ticket/1445

Теперь понял, спасибо за подробное объяснение по этому вопросу.

Кстати, в веб-сервере gws, который обслуживает сайт www.google.com
эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит,
что "This server prefers ChaCha20 suites with clients
that don't have AES-NI (e.g., Android devices)"

--
Best regards,
Gena

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