чт, 20 сент. 2018 г. в 18:01, Maxim Dounin <mdounin@mdounin.ru>:

> Hello!
>
> On Thu, Sep 20, 2018 at 05:40:16AM +0300, Gena Makhomed wrote:
>
> > On 20.09.2018 3:06, Maxim Dounin wrote:
> >
> > >> Правильной была бы цель "сделать обязательной проверку отзыва"
> > >> без каких-либо дополнительных условий?
> >
> > > Именно так. Потому что мешать в одну кучу требование о проверке
> > > отзыва сертфиката и технические аспекты одного из вариантов этой
> > > проверки - это плохой путь.
> >
> > >> Правильным решением в таком случае был бы флаг в сертификате
> > >> "обязательно проверять отзыв сертификата", так что если веб-сервер
> > >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер
> > >> использует его, а если веб-сервер ничего не прислал, тогда браузер
> > >> должен сам в обязательном порядке сделать OCSP-запрос и получить
> ответ?
> > >> И только если браузер не смог получить OCSP-ответ, только в этом
> случае
> > >> запрещать клиенту доступ к сайту с таким флагом в сертификате?
> >
> > > И это было бы логично: именно так сейчас браузеры, использующие
> > > OCSP, и работают, с той лишь разницей, что по результатам
> > > неудачной проверки доступ - не запрещают.
> >
> > Может быть еще не поздно предложить RFC в котором будет
> > описан такой флаг "сделать обязательной проверку отзыва" ?
>
> Лично я - далёк от того, чтобы заниматься вопросами стандартизации
> чего бы то ни было. Возможно, "must staple" сам рано или поздно
> мигрирует в такое поведение.
>
> > >> Такое решение задачи наверное было бы наиболее удобным для создателей
> > >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру
> CA,
> >
> > > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён
> > > по умолчанию во всех браузерах, его использующих.
> >
> > Если не увеличило бы, почему же тогда представители CA были против?
>
> ЕМНИП, на тот момент проверка отзыва был в большинстве браузеров
> по умолчанию выключена.
>
> > >>> В тот момент, когда от клиента пришло соединение с запросом
> > >>> certificate status и OpenSSL'ем был вызван соответствующий
> > >>> callback - у nginx'а нет возможности как-либо отложить обработку
> > >>> этого соединения.
> > >>>
> > >>> Соответственно либо к этому моменту у nginx'а уже есть
> > >>> соответствующий OCSP-ответ - и тогда он может его отправить
> > >>> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не
> > >>> может его отправить, а максимум что может - это инициировать
> > >>> запрос к OCSP-серверу, чтобы этот ответ получить для последующих
> > >>> клиентов.
> >
> > >> У nginx есть отдельный процесс cache manager, который управляет кэшем
> > >> независимо от рабочих процессов nginx, может быть имеет смысл также
> > >> сделать ocsp cache manager, который будет заниматься получением
> > >> и кэшированием OCSP-ответов для всех присутствующих сертификатов?
> >
> > > Можно сделать много всего. Но это не избавляет от ситуации, когда
> > > соединение, в котором надо вернуть OCSP-ответ, уже есть, а самого
> > > OCSP-ответа - ещё нет.
> >
> > Избавляет полностью, если OCSP responder отвечает на запросы.
> >
> > Когда в конфиг добавили новый сертификат и сделали reload -
> > сначала ocsp cache manager убеждается, что у него есть актуальные
> > OCSP-ответы для всех "Must Staple" сертификатов и только после этого
> > применяется новая конфигурация для всех рабочих процессов nginx'а.
> >
> > Когда в конфиг добавили новый сертификат и запустили nginx -
> > сначала запускается ocsp cache manager, убеждается, что у него есть
> > актуальные OCSP-ответы для всех "Must Staple" сертификатов и только
> > после этого запускаются рабочие процессы nginx'а.
> >
> > Когда в процессе работы nginx'а OCSP responder не доступен более
> > чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация
> > и в таком случае nginx просто закрывает соединение с клиентом
> > для всех соединений с "Must Staple" сертификатами до тех пор,
> > пока актуальный OCSP-ответ не будет получен. Это лучше, чем
> > возвращать клиенту "Must Staple" сертификат без OCSP-ответа.
>
> О чём и речь. Во всей этой конструкции - описано множество вещей,
> которые надо программировать, чтобы "must staple" хоть как-то
> заработал. И вещей, которые надо делать на старте nginx'а -
> просто для того, чтобы начать работать. И при этом нет сколь-либо
> разумного решения для ситуации, когда OCSP responder по каким-то
> причинам оказывается недоступен.
>
> Закрывать соединения - это плохой, негодный подход. Очень
> напоминает подход "ошибка аллокации памяти - это форс-мажорная
> ситуация, в таком случае надо делать abort(), это лучше, чем
> продолжать работать".
>
> При этом всего этого можно было бы легко избежать, не пытаясь
> вводить "must staple" вместо требования проверки отзыва.
>
> > >>> Эту проблему можно столь же успешно решить, просто не пытаясь
> > >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать
> > >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу
> > >>> заворачивали" - выглядят, скажем мягко, странно.
> >
> > >> Эта сложная логика уже изобретена и встроена в OpenSSL,
> > >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.
> > >>
> > >> Получается очень красивое решение, так что и Forward Secrecy
> > >> можно получить с большинством браузеров и мобильные клиенты
> > >> будут использовать наиболее эффективный для них шифр ChaCha20.
> >
> > > Это что угодно, но только не красивое решение. Люди потратили
> > > массу сил и времени на изобретение сложной логики (и теперь хотят,
> > > чтобы разработчики nginx'а и все пользователи nginx'а -
> > > присоединились к процессу, потому что встроить эту логику в
> > > существующий механизм выбора приоритета шифров - не осилили).
> > > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям,
> > > сознательно забившим на обновление софта.
> >
> > Не только. Директива ssl_prefer_server_ciphers применяется
> > и в тех случаях, когда в каком-то шифре находят уязвимость,
> > тогда этот шифр с помощью серверных приоритетов ставится
> > на последнее место. Совсем выключить нельзя, потому что
> > некоторые клиенты не умеют ничего другого кроме этого шифра.
> > Такое уже было, например, когда нашли уязвимость в RC4.
> > Или когда до того, наоборот, ставили RC4 на первое место,
> > чтобы защититься от уязвимости в браузерах по имени BEAST.
>
> Случаи с RC4, на самом деле, хороший пример, почему подобноё
> управление шифрами - как раз требует чёткого понимания автором
> конфигурации целей и задач, и требует регулярного пересмотра.
>

есть "конфликт" интересов безопасников и клиентов. безопасники любят
открывать
SSL Labs и тыкать пальцем во все, что не зеленое.

ок ... что это тут у нас ... SSL3 .... отключить.
потом прибегают клиенты, у которых 1С версии 8, в которой в определенных
билдах
только SSL3 и никак иначе

и это без конца.

при то, что на самом деле наличие SSL3 не является проблемой от слова
"совсем"
ну хочешь - соединяйся по TLS 1.2, кто-то тебя насильно тащит на SSL3
чтоли.

периодически возникает мысль, что неплохо бы иметь аналог
ngx_stream_ssl_preread_module для https,
который позволял бы на основании SSL Client Helo отвечать тем способом,
каким хотят увидеть ответ
безопасники (ну или chacha пихнуть, если видим, что пришел андроид)



>
> Потому что RC4 в nginx'е - по умолчанию запрещён начиная с nginx
> 0.8.20, выпущенного в 2009 году. И соответственно сначала все его
> подобавляли для борьбы с BEAST - а потом выпиливали из
> конфигураций обратно, когда стало понятно, что RC4 даже хуже, чем
> считалось до этого. При том, что сколько-нибудь реальной исходная
> проблема с BEAST была - разве что несколько недель после анонса,
> пока браузеры не выкатили свой аналог OpenSSL'ного "insert empty
> fragments".
>
> > В такой ситуации все пользователи nginx'а будут поставлены
> > перед выбором: или защитить клиентов от уязвимости в шифре
> > но при этом быстро съедать батарею у мобильных пользователей
> > или экономить батарею у мобильных пользователей но иметь
> > включенным и выбираемым частью клиентов уязвимый шифр.
> >
> > Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA
> > через директиву конфигурации nginx - это бы упростило жизнь,
> > тогда можно и уязвимый шифр выключить и батарею экономить.
>
> Я не спорю с тем, что соответствующая возможность - может
> оказаться полезной в каких-то ситуациях.
>
> Мне тут в первую очередь печально, что со стороны OpenSSL
> получилось очередной ad-hoc решение, требующее отдельной ручки -
> вместо, например, групп шифров с одинаковым приоритетом в строке
> спецификации шифров.
>
> Ну и равно печально, что люди не понимают, что включать
> ssl_prefer_server_ciphers в отсутствии серьёзных проблем, которые
> нужно решать на стороне сервера - не стоит.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru