On Thu, Sep 20, 2018, 7:40 AM Gena Makhomed <gmm@csdoc.com> wrote:

> On 20.09.2018 3:06, Maxim Dounin wrote:
>
> >> Правильной была бы цель "сделать обязательной проверку отзыва"
> >> без каких-либо дополнительных условий?
>
> > Именно так. Потому что мешать в одну кучу требование о проверке
> > отзыва сертфиката и технические аспекты одного из вариантов этой
> > проверки - это плохой путь.
>
> >> Правильным решением в таком случае был бы флаг в сертификате
> >> "обязательно проверять отзыв сертификата", так что если веб-сервер
> >> прислал OCSP-ответ прикрепленный к сертификату сервером, браузер
> >> использует его, а если веб-сервер ничего не прислал, тогда браузер
> >> должен сам в обязательном порядке сделать OCSP-запрос и получить ответ?
> >> И только если браузер не смог получить OCSP-ответ, только в этом случае
> >> запрещать клиенту доступ к сайту с таким флагом в сертификате?
>
> > И это было бы логично: именно так сейчас браузеры, использующие
> > OCSP, и работают, с той лишь разницей, что по результатам
> > неудачной проверки доступ - не запрещают.
>
> Может быть еще не поздно предложить RFC в котором будет
> описан такой флаг "сделать обязательной проверку отзыва" ?
>
> >> Такое решение задачи наверное было бы наиболее удобным для создателей
> >> веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA,
>
> > Не увеличило бы. Потому что по факту - OCSP сейчас и так включён
> > по умолчанию во всех браузерах, его использующих.
>
> Если не увеличило бы, почему же тогда представители CA были против?
>
> ========================================
>
> On 18.09.2018 22:09, Maxim Dounin wrote:
>
> > Было предложено сделать отдельный флаг в сертификатах, требующий
> > hard fail для конкретного сертификата. Но это в свою очередь не
> > понравилось представителям CA, так как они справедливо полагали,
> > что подобные сертификаты могут создать серьёзную нагрузку на
> > OCSP-сервера (как, впрочем, и на CRL Distribution Points, но
> > браузеры сейчас фактически не пользуются CRL в чистом виде). И
> > "must staple" получился как некоторый итог этого столкновения
> > интересов.
>
> ========================================
>
> >>> В тот момент, когда от клиента пришло соединение с запросом
> >>> 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'а.
>

это выглядит как более удобное решение, чем текущая реализация stapling.
объясню.

у нас на момент запуска nginx доступ до сети скорее отсутствует, чем
присутствует (серверу надо добиться сходимости OSPF)
на момент, когда OSPF уже сошелся, на сервер идут запросы, он должен на них
отвечать

если мы включаем stapling, это выглядит так

1) не, посоны, у вас сети нет, я stapling не могу включить, живите с
отключенным
2) после сходимости OSPF можно сделать еще один reload, тогда stapling
включается


примерно такая же лотерея возникает при ситуации, когда целиком выключается
датацентр.
включится ли сервер с nginx после того, как запустится сетевое оборудование
? в зависимисоти от этого
stapling либо включается, либо нет.

вы скажете "а что вы хотели, это же выключение цода". я отвечу, что при
выключении цода у меня обычно хватает забот,
и мне не до тонкого траблшутинга "а не подергать ли nginx, чтобы он
правильно применил stapling"





>
> Когда в конфиг добавили новый сертификат и запустили nginx -
> сначала запускается ocsp cache manager, убеждается, что у него есть
> актуальные OCSP-ответы для всех "Must Staple" сертификатов и только
> после этого запускаются рабочие процессы nginx'а.
>
>
>
>
>
> Когда в процессе работы nginx'а OCSP responder не доступен более
> чем 50% времени жизни OCSP-ответа - это форс-мажорная ситуация
> и в таком случае nginx просто закрывает соединение с клиентом
> для всех соединений с "Must Staple" сертификатами до тех пор,
> пока актуальный OCSP-ответ не будет получен. Это лучше, чем
> возвращать клиенту "Must Staple" сертификат без OCSP-ответа.
>
> >>> Эту проблему можно столь же успешно решить, просто не пытаясь
> >>> включать "ssl_prefer_server_ciphers". Попытки же изобретать
> >>> сложную логику - "здесь играем, здесь не играем, здесь рыбу
> >>> заворачивали" - выглядят, скажем мягко, странно.
>
> >> Эта сложная логика уже изобретена и встроена в OpenSSL,
> >> достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.
> >>
> >> Получается очень красивое решение, так что и Forward Secrecy
> >> можно получить с большинством браузеров и мобильные клиенты
> >> будут использовать наиболее эффективный для них шифр ChaCha20.
>
> > Это что угодно, но только не красивое решение. Люди потратили
> > массу сил и времени на изобретение сложной логики (и теперь хотят,
> > чтобы разработчики nginx'а и все пользователи nginx'а -
> > присоединились к процессу, потому что встроить эту логику в
> > существующий механизм выбора приоритета шифров - не осилили).
> > И всё ради того, чтобы насильно обеспечить Forward Secrecy людям,
> > сознательно забившим на обновление софта.
>
> Не только. Директива ssl_prefer_server_ciphers применяется
> и в тех случаях, когда в каком-то шифре находят уязвимость,
> тогда этот шифр с помощью серверных приоритетов ставится
> на последнее место. Совсем выключить нельзя, потому что
> некоторые клиенты не умеют ничего другого кроме этого шифра.
> Такое уже было, например, когда нашли уязвимость в RC4.
> Или когда до того, наоборот, ставили RC4 на первое место,
> чтобы защититься от уязвимости в браузерах по имени BEAST.
>
> В такой ситуации все пользователи nginx'а будут поставлены
> перед выбором: или защитить клиентов от уязвимости в шифре
> но при этом быстро съедать батарею у мобильных пользователей
> или экономить батарею у мобильных пользователей но иметь
> включенным и выбираемым частью клиентов уязвимый шифр.
>
> Если бы была возможность включить SSL_OP_PRIORITIZE_CHACHA
> через директиву конфигурации nginx - это бы упростило жизнь,
> тогда можно и уязвимый шифр выключить и батарею экономить.
>
> --
> Best regards,
> Gena
>
> _______________________________________________
> 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