<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">ср, 19 сент. 2018 г. в 2:26, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18.09.2018 20:03, Maxim Dounin wrote:<br>
<br>
>>>> Кстати, пользователи жалуются, что есть BUG в nginx,<br>
>>>> связанный с сертификатами с флагом "OCSP Must Staple":<br>
>>>> <a href="https://blog.crashed.org/nginx-stapling-busted/" rel="noreferrer" target="_blank">https://blog.crashed.org/nginx-stapling-busted/</a><br>
<br>
>>> Потому что "Must Staple" - это попытка превратить OCSP stapling<br>
>>> из механизма оптимизации в обязательный механизм, аналогичный<br>
>>> короткоживущим сертификатам. Не сюрприз, что так не работает -<br>
>>> требования совершенно разные.<br>
<br>
>> RFC 7633 был создан сотрудником Comodo, в RFC он пишет,<br>
>> что цель RFC - "prevents a denial-of-service attack".<br>
>><br>
>> Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder<br>
>> - клиенты не смогут отличить отозванный сертификат от действительного.<br>
>><br>
>> При массовом внедрении флага OCSP Must-Staple в сертификаты<br>
>> - делать DDoS-атаки на OCSP responder не будет иметь смысла.<br>
>><br>
>> То есть цель у флага OCSP Must-Staple наверное та же самая,<br>
>> что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA.<br>
<br>
> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать<br>
> обязательной проверку отзыва, не нагружая дополнительно<br>
> инфраструктуру CA.<br>
> <br>
> Проблема в том, что нельзя просто так взять механизм оптимизации и<br>
> сделать из него механизм контроля, это две разные задачи, которые<br>
> надо решать по-разному.<br>
<br>
Если задача стоит "сделать обязательной проверку отзыва,<br>
не нагружая дополнительно инфраструктуру CA" - как же можно<br>
решить эту задачу другими методами, без флага Must Staple?<br></blockquote><div><br></div><div><br></div><div>   SSL   соединение может быть установлено, если сервер использует <br></div><div><br></div><div>а) действующий сертификат (на текущий момент времени)<br></div><div>б) сертификат серверного типа</div><div>в) сертификат не отозван (это можно проверить через  CRL)</div><div><br></div><div><br></div><div>это, собственно, "другие" методы. известные еще нашим отцам и дедам.<br></div><div>но исторически в части    CRL   все работало не очень стабильно, и браузеры де факто</div><div>не делают проблемы, если не могут скачать CRL</div><div><br></div><div>вероятно, они так же не будут делать проблемы с сертами Must Staple<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ведь флаг "обязательно проверять отзыв через OCSP" создаст<br>
очень большую нагрузку на CA - это будет хуже чем Must Staple.<br>
Тем более, что сейчас Google Chrome OCSP вообще не использует.<br>
<br>
Если добавить в сертификат флаг о том, как следует относиться<br>
к ошибкам проверки отзыва сертификата - у него может быть всего<br>
два варианта, soft fail (то же самое что и отсутствие этого флага),<br>
и hard fail, это вариант "Must Staple" перенесенный на уровень браузера,<br>
то есть это будет равно флагу "обязательно проверять отзыв через OCSP".<br>
<br>
>>> Любители Must Staple общаются в траке в двух тикетах:<br>
>>><br>
>>> <a href="https://trac.nginx.org/nginx/ticket/812" rel="noreferrer" target="_blank">https://trac.nginx.org/nginx/ticket/812</a><br>
>>> <a href="https://trac.nginx.org/nginx/ticket/990" rel="noreferrer" target="_blank">https://trac.nginx.org/nginx/ticket/990</a><br>
>>><br>
>>> Пока что они делают это с нулевым полезным выходом.<br>
<br>
>> Они в основном там просят сделать возможным указывать в конфиге<br>
>> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов.<br>
>><br>
>> Но есть ведь и другие способы решения этой проблемы, например,<br>
>> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того,<br>
>> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто<br>
>> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер.<br>
<br>
> Проблема для начала в том, что в OpenSSL нет возможности подождать<br>
> получения OCSP-ответа, не блокируя рабочий процесс nginx'а.<br>
<br>
Насколько я понимаю из исходников, nginx делает запрос к OCSP<br>
серверу самостоятельно, не блокируя рабочий процесс nginx'а.<br>
<br>
Очень похожий функционал запроса с "ожиданием" уже реализован в nginx,<br>
в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется.<br>
<br>
> Я не считаю использование "ssl_prefer_server_ciphers on"<br>
> правильным приблизительно нигде, кроме ситуаций, когда автор<br>
> конфигурации чётко понимает, чего он хочет добиться, и регулярно<br>
> занимается анализом и пересмотром списка используемых шифров.<br>
> <br>
> И даже в этом случае - его использование подчас выходит боком, как<br>
> например с выбором AES vs. ChaCha20:<br>
> <br>
> <a href="https://trac.nginx.org/nginx/ticket/1445" rel="noreferrer" target="_blank">https://trac.nginx.org/nginx/ticket/1445</a><br>
<br>
Теперь понял, спасибо за подробное объяснение по этому вопросу.<br></blockquote><div><br></div><div><br></div><div> на Xeon chacha20 проигрывает, мы сравнили</div><div><br></div><div>openssl speed -evp  chacha20</div><div><br></div><div>с<br></div><div><br></div><div>openssl speed -evp  aes-128-gcm</div><div><br></div><div>желание приоритезировать chacha20 отпало<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Кстати, в веб-сервере gws, который обслуживает сайт <a href="http://www.google.com" rel="noreferrer" target="_blank">www.google.com</a><br>
эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит,<br>
что "This server prefers ChaCha20 suites with clients<br>
that don't have AES-NI (e.g., Android devices)"<br>
<br>
-- <br>
Best regards,<br>
  Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>