OCSP stapling in Nginx >=1.3.7

Ср Сен 19 22:31:53 UTC 2018

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