<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">вт, 18 сент. 2018 г. в 19:01, 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 17.09.2018 2:36, Maxim Dounin wrote:<br>
<br>
>>>>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять<br>
>>>>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного<br>
>>>>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью<br>
>>>>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет.<br>
<br>
Над OCSP в OpenSSL работал Rob Stradling из Comodo, может быть имеет<br>
смысл к нему обратиться с просьбой исправить эту проблему в OpenSSL?<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></blockquote><div><br></div><div>вы и правы и неправы одновременно.</div><div>Must-Staple обязывает отдать OCSP ответ.</div><div><br></div><div>вопрос в том, как с OCSP будет работать https-сервер. если он попытается пойти за OCSP в момент, когда к нему подключается браузер (а инфраструктура CA "лежит"),</div><div>то это одно. если https-сервер озаботился и сходил за OCSP заранее, то наличие или отсутствие работающей инфраструктуры CA становится менее важным.</div><div><br></div><div>полностью исключить инфраструктуру СА из цепочки нельзя в силу дизайна протокола (надо будет почитать, допустимы ли кросс-подписи для OCSP ....)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
То есть цель у флага OCSP Must-Staple наверное та же самая,<br>
что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA.<br></blockquote><div><br></div><div> цель у этого флага непонятна никому. есть ощущение, что (как и многие аспекты TLS/SSL) это просто не очень продуманный дизайн.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Кстати, тест на <a href="http://ssllabs.com" rel="noreferrer" target="_blank">ssllabs.com</a> показывает OCSP Must-Staple зеленым цветом.<br>
Ivan Ristic как бы намекает, что это полезный флаг и его стоит включить.<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>
Разумеется, не отправлять ответ клиенту без OCSP Stapling'а имеет смысл<br>
только для тех сертификатов, у которых установлен флаг OCSP Must-Staple.<br>
<br>
P.S.<br>
<br>
Кстати, если посмотреть через <a href="https://www.ssllabs.com/ssltest/" rel="noreferrer" target="_blank">https://www.ssllabs.com/ssltest/</a><br>
на сайты <a href="http://nginx.org" rel="noreferrer" target="_blank">nginx.org</a> и <a href="http://nginx.com" rel="noreferrer" target="_blank">nginx.com</a>, то видно, что с <a href="http://nginx.org" rel="noreferrer" target="_blank">nginx.org</a> все<br>
нормально, а вот <a href="http://nginx.com" rel="noreferrer" target="_blank">nginx.com</a> настроен не совсем оптимально.<br>
<br>
Наверное самый простой вариант корректной настройки сервера:<br>
<br>
# OpenSSL, ssl_ciphers и nginx: прокачиваем на 100%<br>
# <a href="https://habrahabr.ru/post/325230/" rel="noreferrer" target="_blank">https://habrahabr.ru/post/325230/</a><br>
<br>
ssl_prefer_server_ciphers on;<br>
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1;<br>
ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;<br>
<br>
Может быть имеет смысл сделать эти значения<br>
значениями по-умолчанию в nginx?<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>