<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">чт, 20 сент. 2018 г. в 18:01, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Thu, Sep 20, 2018 at 05:40:16AM +0300, Gena Makhomed wrote:<br>
<br>
> 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>
чего бы то ни было.   Возможно, "must staple" сам рано или поздно <br>
мигрирует в такое поведение.<br>
<br>
> >> Такое решение задачи наверное было бы наиболее удобным для создателей<br>
> >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA,<br>
> <br>
> > Не увеличило бы.  Потому что по факту - OCSP сейчас и так включён<br>
> > по умолчанию во всех браузерах, его использующих.<br>
> <br>
> Если не увеличило бы, почему же тогда представители CA были против?<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>
> <br>
> Когда в конфиг добавили новый сертификат и запустили nginx -<br>
> сначала запускается ocsp cache manager, убеждается, что у него есть<br>
> актуальные OCSP-ответы для всех "Must Staple" сертификатов и только<br>
> после этого запускаются рабочие процессы nginx'а.<br>
> <br>
> Когда в процессе работы nginx'а OCSP responder не доступен более<br>
> чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация<br>
> и в таком случае nginx просто закрывает соединение с клиентом<br>
> для всех соединений с "Must Staple" сертификатами до тех пор,<br>
> пока актуальный OCSP-ответ не будет получен. Это лучше, чем<br>
> возвращать клиенту "Must Staple" сертификат без OCSP-ответа.<br>
<br>
О чём и речь.  Во всей этой конструкции - описано множество вещей, <br>
которые надо программировать, чтобы "must staple" хоть как-то <br>
заработал.  И вещей, которые надо делать на старте nginx'а - <br>
просто для того, чтобы начать работать.  И при этом нет сколь-либо <br>
разумного решения для ситуации, когда OCSP responder по каким-то <br>
причинам оказывается недоступен.<br>
<br>
Закрывать соединения - это плохой, негодный подход.  Очень <br>
напоминает подход "ошибка аллокации памяти - это форс-мажорная <br>
ситуация, в таком случае надо делать abort(), это лучше, чем <br>
продолжать работать".<br>
<br>
При этом всего этого можно было бы легко избежать, не пытаясь <br>
вводить "must staple" вместо требования проверки отзыва.<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>
Случаи с RC4, на самом деле, хороший пример, почему подобноё <br>
управление шифрами - как раз требует чёткого понимания автором <br>
конфигурации целей и задач, и требует регулярного пересмотра.<br></blockquote><div><br></div><div>есть "конфликт" интересов безопасников и клиентов. безопасники любят открывать</div><div>SSL Labs и тыкать пальцем во все, что не зеленое.</div><div><br></div><div>ок ... что это тут у нас ...  SSL3 .... отключить.</div><div>потом прибегают клиенты, у которых 1С версии 8, в которой в определенных билдах</div><div>только SSL3 и никак иначе</div><div><br></div><div>и это без конца.</div><div><br></div><div>при то, что на самом деле наличие SSL3 не является проблемой от слова "совсем"</div><div>ну хочешь - соединяйся по TLS 1.2, кто-то тебя насильно тащит на  SSL3 чтоли.</div><div><br></div><div>периодически возникает мысль, что неплохо бы иметь аналог ngx_stream_ssl_preread_module для https,</div><div>который позволял бы на основании SSL Client Helo отвечать тем способом, каким хотят увидеть ответ</div><div>безопасники (ну или chacha пихнуть, если видим, что пришел андроид)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Потому что RC4 в nginx'е - по умолчанию запрещён начиная с nginx <br>
0.8.20, выпущенного в 2009 году.  И соответственно сначала все его <br>
подобавляли для борьбы с BEAST - а потом выпиливали из <br>
конфигураций обратно, когда стало понятно, что RC4 даже хуже, чем <br>
считалось до этого.  При том, что сколько-нибудь реальной исходная <br>
проблема с BEAST была - разве что несколько недель после анонса, <br>
пока браузеры не выкатили свой аналог OpenSSL'ного "insert empty <br>
fragments".<br>
<br>
> В такой ситуации все пользователи nginx'а будут поставлены<br>
> перед выбором: или защитить клиентов от уязвимости в шифре<br>
> но при этом быстро съедать батарею у мобильных пользователей<br>
> или экономить батарею у мобильных пользователей но иметь<br>
> включенным и выбираемым частью клиентов уязвимый шифр.<br>
> <br>
> Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA<br>
> через директиву конфигурации nginx - это бы упростило жизнь,<br>
> тогда можно и уязвимый шифр выключить и батарею экономить.<br>
<br>
Я не спорю с тем, что соответствующая возможность - может <br>
оказаться полезной в каких-то ситуациях.<br>
<br>
Мне тут в первую очередь печально, что со стороны OpenSSL <br>
получилось очередной ad-hoc решение, требующее отдельной ручки - <br>
вместо, например, групп шифров с одинаковым приоритетом в строке <br>
спецификации шифров.<br>
<br>
Ну и равно печально, что люди не понимают, что включать <br>
ssl_prefer_server_ciphers в отсутствии серьёзных проблем, которые <br>
нужно решать на стороне сервера - не стоит.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><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></div>