Gena Makhomed
September 19, 2018 06:32PM
On 19.09.2018 21:56, Maxim Dounin wrote:

>>> Цель "Must Staple", как она обсуждалась на cabforum'е - сделать
>>> обязательной проверку отзыва, не нагружая дополнительно
>>> инфраструктуру CA.

>>> Проблема в том, что нельзя просто так взять механизм оптимизации и
>>> сделать из него механизм контроля, это две разные задачи, которые
>>> надо решать по-разному.

>> Если задача стоит "сделать обязательной проверку отзыва,
>> не нагружая дополнительно инфраструктуру CA" - как же можно
>> решить эту задачу другими методами, без флага Must Staple?

> Всё так, именно этой цели соответствует решение "must staple".
> Проблема тут во многом - в целеполагании.

Правильной была бы цель "сделать обязательной проверку отзыва"
без каких-либо дополнительных условий?

Правильным решением в таком случае был бы флаг в сертификате
"обязательно проверять отзыв сертификата", так что если веб-сервер
прислал OCSP-ответ прикрепленный к сертификату сервером, браузер
использует его, а если веб-сервер ничего не прислал, тогда браузер
должен сам в обязательном порядке сделать OCSP-запрос и получить ответ?
И только если браузер не смог получить OCSP-ответ, только в этом случае
запрещать клиенту доступ к сайту с таким флагом в сертификате?

Такое решение задачи наверное было бы наиболее удобным для создателей
веб-серверов, но значительно увеличило бы нагрузку на инфраструктуру CA,
потому что OCSP Stapling по умолчанию выключен в nginx и нет
никаких вариантов, чтобы сделать "ssl_stapling on" по-умолчанию
из-за необходимости вручную указывать настройки resolver в конфиге?

Для предотвращения DNS-спуфинга ничего иного нельзя придумать, кроме
как "использовать DNS-серверы в защищённой доверенной локальной сети"?

>>>> Они в основном там просят сделать возможным указывать в конфиге
>>>> несколько директив ssl_stapling_file для ECDSA и RSA сертификатов.
>>>>
>>>> Но есть ведь и другие способы решения этой проблемы, например,
>>>> чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того,
>>>> как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто
>>>> сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер.

>>> Проблема для начала в том, что в OpenSSL нет возможности подождать
>>> получения OCSP-ответа, не блокируя рабочий процесс nginx'а.

>> Насколько я понимаю из исходников, nginx делает запрос к OCSP
>> серверу самостоятельно, не блокируя рабочий процесс nginx'а.
>>
>> Очень похожий функционал запроса с "ожиданием" уже реализован в nginx,
>> в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется.

> В тот момент, когда от клиента пришло соединение с запросом
> certificate status и OpenSSL'ем был вызван соответствующий
> callback - у nginx'а нет возможности как-либо отложить обработку
> этого соединения.
>
> Соответственно либо к этому моменту у nginx'а уже есть
> соответствующий OCSP-ответ - и тогда он может его отправить
> клиенту, либо соответствующего OCSP-ответа нет - и тогда он не
> может его отправить, а максимум что может - это инициировать
> запрос к OCSP-серверу, чтобы этот ответ получить для последующих
> клиентов.

У nginx есть отдельный процесс cache manager, который управляет кэшем
независимо от рабочих процессов nginx, может быть имеет смысл также
сделать ocsp cache manager, который будет заниматься получением
и кэшированием OCSP-ответов для всех присутствующих сертификатов?

Этот ocsp cache manager может следить за тем, чтобы OCSP-ответы
всегда были не устаревшими, и если прошло, например, 50% или 66%
времени жизни OCSP-ответа, - тогда он инициирует новый OCSP-запрос
и складывает ответы в файловую систему (для быстрого перезапуска)
а также в shared memory для быстрого доступа из рабочих процессов nginx.

Чтобы минимизировать вероятность получение клиентом ответа сервера
без прикрепленного к сертификату OCSP-ответа - ocsp cache manager
должен при старте проверить есть ли у него в кэше OCSP-ответы
для всех сертификатов, и если нет - сразу же инициировать
получение OCSP-ответа, не дожидаясь пока придет первый
запрос от клиента.

Наверное будет лучше если рабочие процессы nginx'а для SSL-соединений
с сертификатами с флагом "Must Staple" будут делать return 444 если
у них нет в наличии актуального OCSP-ответа для этого сертификата.
Все равно ведь без OCSP-ответа браузеры не будут открывать сайт.

>>> Я не считаю использование "ssl_prefer_server_ciphers on"
>>> правильным приблизительно нигде, кроме ситуаций, когда автор
>>> конфигурации чётко понимает, чего он хочет добиться, и регулярно
>>> занимается анализом и пересмотром списка используемых шифров.

>>> И даже в этом случае - его использование подчас выходит боком, как
>>> например с выбором AES vs. ChaCha20:
>>>
>>> https://trac.nginx.org/nginx/ticket/1445

>> Теперь понял, спасибо за подробное объяснение по этому вопросу.
>>
>> Кстати, в веб-сервере gws, который обслуживает сайт www.google.com
>> эта проблема с AES vs. ChaCha20 уже успешно решена, ssltest говорит,
>> что "This server prefers ChaCha20 suites with clients
>> that don't have AES-NI (e.g., Android devices)"

> Эту проблему можно столь же успешно решить, просто не пытаясь
> включать "ssl_prefer_server_ciphers". Попытки же изобретать
> сложную логику - "здесь играем, здесь не играем, здесь рыбу
> заворачивали" - выглядят, скажем мягко, странно.

Эта сложная логика уже изобретена и встроена в OpenSSL,
достаточно только указать флаг SSL_OP_PRIORITIZE_CHACHA.

Получается очень красивое решение, так что и Forward Secrecy
можно получить с большинством браузеров и мобильные клиенты
будут использовать наиболее эффективный для них шифр ChaCha20.

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html

SSL_OP_PRIORITIZE_CHACHA

When SSL_OP_CIPHER_SERVER_PREFERENCE is set, temporarily reprioritize
ChaCha20-Poly1305 ciphers to the top of the server cipher list if a
ChaCha20-Poly1305 cipher is at the top of the client cipher list. This
helps those clients (e.g. mobile) use ChaCha20-Poly1305 if that cipher
is anywhere in the server cipher list; but still allows other clients to
use AES and other ciphers. Requires SSL_OP_CIPHER_SERVER_PREFERENCE.

--
Best regards,
Gena

_______________________________________________
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: 55
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready