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
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
