Илья Шипицин
September 20, 2018 02:32AM
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
Subject Author Posted

OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 06, 2018 11:28AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 10, 2018 09:06AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 10, 2018 03:40PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 10, 2018 04:24PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 10, 2018 05:01PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 03:08AM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 10, 2018 04:52PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 10, 2018 11:22PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 04:12AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 04:16AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 11, 2018 08:40AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 10:42AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 11, 2018 11:06AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 11, 2018 12:00PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 11, 2018 03:00PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 12, 2018 10:38AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 15, 2018 07:36AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 16, 2018 07:38PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 17, 2018 09:06AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 18, 2018 10:02AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 12:20PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 01:30PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 01:50PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 03:10PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 18, 2018 01:04PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 18, 2018 04:10PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 06:54PM

Re: OCSP stapling in Nginx >=1.3.7

ngnx8810773a83 September 19, 2018 07:46PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 18, 2018 05:28PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 18, 2018 06:00PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 03:26PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 19, 2018 03:54PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 02:58PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 06:32PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 19, 2018 08:08PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 19, 2018 10:42PM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 20, 2018 02:32AM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 20, 2018 09:02AM

Re: OCSP stapling in Nginx >=1.3.7

Илья Шипицин September 20, 2018 09:52AM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 20, 2018 01:56PM

Re: OCSP stapling in Nginx >=1.3.7

Maxim Dounin September 20, 2018 07:48PM

Re: OCSP stapling in Nginx >=1.3.7

Gena Makhomed September 21, 2018 12:42PM

How to Improve SEO with HTTPS and NGINX

Gena Makhomed September 15, 2018 11:22AM

Re: How to Improve SEO with HTTPS and NGINX

Maxim Dounin September 16, 2018 07:44PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 103
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready