<div dir="ltr"><br><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018, 7:40 AM Gena Makhomed <<a href="mailto:gmm@csdoc.com" target="_blank">gmm@csdoc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20.09.2018 3:06, Maxim Dounin wrote:<br>
<br>
>> Правильной была бы цель "сделать обязательной проверку отзыва"<br>
>> без каких-либо дополнительных условий?<br>
<br>
> Именно так. Потому что мешать в одну кучу требование о проверке<br>
> отзыва сертфиката и технические аспекты одного из вариантов этой<br>
> проверки - это плохой путь.<br>
<br>
>> Правильным решением в таком случае был бы флаг в сертификате<br>
>> "обязательно проверять отзыв сертификата", так что если веб-сервер<br>
>> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер<br>
>> использует его, а если веб-сервер ничего не прислал, тогда браузер<br>
>> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ?<br>
>> И только если браузер не смог получить OCSP-ответ, только в этом случае<br>
>> запрещать клиенту доступ к сайту с таким флагом в сертификате?<br>
<br>
> И это было бы логично: именно так сейчас браузеры, использующие<br>
> OCSP, и работают, с той лишь разницей, что по результатам<br>
> неудачной проверки доступ - не запрещают.<br>
<br>
Может быть еще не поздно предложить RFC в котором будет<br>
описан такой флаг "сделать обязательной проверку отзыва" ?<br>
<br>
>> Такое решение задачи наверное было бы наиболее удобным для создателей<br>
>> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA,<br>
<br>
> Не увеличило бы.  Потому что по факту - OCSP сейчас и так включён<br>
> по умолчанию во всех браузерах, его использующих.<br>
<br>
Если не увеличило бы, почему же тогда представители CA были против?<br>
<br>
========================================<br>
<br>
On 18.09.2018 22:09, Maxim Dounin wrote:<br>
<br>
 > Было предложено сделать отдельный флаг в сертификатах, требующий<br>
 > hard fail для конкретного сертификата. Но это в свою очередь не<br>
 > понравилось представителям CA, так как они справедливо полагали,<br>
 > что подобные сертификаты могут создать серьёзную нагрузку на<br>
 > OCSP-сервера (как, впрочем, и на CRL Distribution Points, но<br>
 > браузеры сейчас фактически не пользуются CRL в чистом виде).  И<br>
 > "must staple" получился как некоторый итог этого столкновения<br>
 > интересов.<br>
<br>
========================================<br>
<br>
>>> В тот момент, когда от клиента пришло соединение с запросом<br>
>>> certificate status и OpenSSL'ем был вызван соответствующий<br>
>>> callback - у nginx'а нет возможности как-либо отложить обработку<br>
>>> этого соединения.<br>
>>><br>
>>> Соответственно либо к этому моменту у nginx'а уже есть<br>
>>> соответствующий OCSP-ответ - и тогда он может его отправить<br>
>>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не<br>
>>> может его отправить, а максимум что может - это инициировать<br>
>>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих<br>
>>> клиентов.<br>
<br>
>> У nginx есть отдельный процесс cache manager, который управляет кэшем<br>
>> независимо от рабочих процессов nginx, может быть имеет смысл также<br>
>> сделать ocsp cache manager, который будет заниматься получением<br>
>> и кэшированием OCSP-ответов для всех присутствующих сертификатов?<br>
<br>
> Можно сделать много всего.  Но это не избавляет от ситуации, когда<br>
> соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого<br>
> OCSP-ответа - ещё нет.<br>
<br>
Избавляет полностью, если OCSP responder отвечает на запросы.<br>
<br>
Когда в конфиг добавили новый сертификат и сделали reload -<br>
сначала ocsp cache manager убеждается, что у него есть актуальные<br>
OCSP-ответы для всех "Must Staple" сертификатов и только после этого<br>
применяется новая конфигурация для всех рабочих процессов nginx'а.<br></blockquote><div><br></div><div>это выглядит как более удобное решение, чем текущая реализация stapling.</div><div>объясню.</div><div><br></div><div>у нас на момент запуска nginx доступ до сети скорее отсутствует, чем присутствует (серверу надо добиться сходимости OSPF)</div><div>на момент, когда OSPF уже сошелся, на сервер идут запросы, он должен на них отвечать</div><div><br></div><div>если мы включаем stapling, это выглядит так</div><div><br></div><div>1) не, посоны, у вас сети нет, я stapling не могу включить, живите с отключенным</div><div>2) после сходимости OSPF можно сделать еще один  reload, тогда stapling включается</div><div><br></div><div><br></div><div>примерно такая же лотерея возникает при ситуации, когда целиком выключается датацентр.</div><div>включится ли сервер с nginx после того, как запустится сетевое оборудование ? в зависимисоти от этого</div><div>stapling либо включается, либо нет.</div><div><br></div><div>вы скажете "а что вы хотели, это же выключение цода". я отвечу, что при выключении цода у меня обычно хватает забот,</div><div>и мне не до тонкого траблшутинга "а не подергать ли nginx, чтобы он правильно применил stapling"<br></div><div><br></div><div><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>
Когда в конфиг добавили новый сертификат и запустили nginx -<br>
сначала запускается ocsp cache manager, убеждается, что у него есть<br>
актуальные OCSP-ответы для всех "Must Staple" сертификатов и только<br>
после этого запускаются рабочие процессы nginx'а.<br>
<br><br><br><br><br>
Когда в процессе работы nginx'а OCSP responder не доступен более<br>
чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация<br>
и в таком случае nginx просто закрывает соединение с клиентом<br>
для всех соединений с "Must Staple" сертификатами до тех пор,<br>
пока актуальный OCSP-ответ не будет получен. Это лучше, чем<br>
возвращать клиенту "Must Staple" сертификат без OCSP-ответа.<br>
<br>
>>> Эту проблему можно столь же успешно решить, просто не пытаясь<br>
>>> включать "ssl_prefer_server_ciphers".  Попытки же изобретать<br>
>>> сложную логику - "здесь играем, здесь не играем, здесь рыбу<br>
>>> заворачивали" - выглядят, скажем мягко, странно.<br>
<br>
>> Эта сложная логика уже изобретена и встроена в OpenSSL,<br>
>> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.<br>
>><br>
>> Получается очень красивое решение, так что и Forward Secrecy<br>
>> можно получить с большинством браузеров и мобильные клиенты<br>
>> будут использовать наиболее эффективный для них шифр ChaCha20.<br>
<br>
> Это что угодно, но только не красивое решение. Люди потратили<br>
> массу сил и времени на изобретение сложной логики (и теперь хотят,<br>
> чтобы разработчики nginx'а и все пользователи nginx'а -<br>
> присоединились к процессу, потому что встроить эту логику в<br>
> существующий механизм выбора приоритета шифров - не осилили). <br>
> И всё ради того, чтобы насильно обеспечить Forward Secrecy людям,<br>
> сознательно забившим на обновление софта.<br>
<br>
Не только. Директива ssl_prefer_server_ciphers применяется<br>
и в тех случаях, когда в каком-то шифре находят уязвимость,<br>
тогда этот шифр с помощью серверных приоритетов ставится<br>
на последнее место. Совсем выключить нельзя, потому что<br>
некоторые клиенты не умеют ничего другого кроме этого шифра.<br>
Такое уже было, например, когда нашли уязвимость в RC4.<br>
Или когда до того, наоборот, ставили RC4 на первое место,<br>
чтобы защититься от уязвимости в браузерах по имени BEAST.<br>
<br>
В такой ситуации все пользователи nginx'а будут поставлены<br>
перед выбором: или защитить клиентов от уязвимости в шифре<br>
но при этом быстро съедать батарею у мобильных пользователей<br>
или экономить батарею у мобильных пользователей но иметь<br>
включенным и выбираемым частью клиентов уязвимый шифр.<br>
<br>
Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA<br>
через директиву конфигурации nginx - это бы упростило жизнь,<br>
тогда можно и уязвимый шифр выключить и батарею экономить.<br>
<br>
-- <br>
Best regards,<br>
  Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" rel="noreferrer" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div></div></div>