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, на самом деле, хороший пример, почему подобноё
управление шифрами - как раз требует чёткого понимания автором
конфигурации целей и задач, и требует регулярного пересмотра.

Потому что 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