On 18.09.2018 20:03, Maxim Dounin wrote:
Кстати, пользователи жалуются, что есть BUG в nginx, связанный с сертификатами с флагом "OCSP Must Staple": https://blog.crashed.org/nginx-stapling-busted/
Потому что "Must Staple" - это попытка превратить OCSP stapling из механизма оптимизации в обязательный механизм, аналогичный короткоживущим сертификатам. Не сюрприз, что так не работает - требования совершенно разные.
RFC 7633 был создан сотрудником Comodo, в RFC он пишет, что цель RFC - "prevents a denial-of-service attack". Сейчас, если кто-то с помощью DDoS-атаки заблокирует OCSP responder - клиенты не смогут отличить отозванный сертификат от действительного. При массовом внедрении флага OCSP Must-Staple в сертификаты - делать DDoS-атаки на OCSP responder не будет иметь смысла. То есть цель у флага OCSP Must-Staple наверное та же самая, что и у OCSP Stapling - снизить нагрузку на инфраструктуру CA.
Цель "Must Staple", как она обсуждалась на cabforum'е - сделать обязательной проверку отзыва, не нагружая дополнительно инфраструктуру CA. Проблема в том, что нельзя просто так взять механизм оптимизации и сделать из него механизм контроля, это две разные задачи, которые надо решать по-разному.
Если задача стоит "сделать обязательной проверку отзыва, не нагружая дополнительно инфраструктуру CA" - как же можно решить эту задачу другими методами, без флага Must Staple? Ведь флаг "обязательно проверять отзыв через OCSP" создаст очень большую нагрузку на CA - это будет хуже чем Must Staple. Тем более, что сейчас Google Chrome OCSP вообще не использует. Если добавить в сертификат флаг о том, как следует относиться к ошибкам проверки отзыва сертификата - у него может быть всего два варианта, soft fail (то же самое что и отсутствие этого флага), и hard fail, это вариант "Must Staple" перенесенный на уровень браузера, то есть это будет равно флагу "обязательно проверять отзыв через OCSP".
Любители Must Staple общаются в траке в двух тикетах: https://trac.nginx.org/nginx/ticket/812 https://trac.nginx.org/nginx/ticket/990 Пока что они делают это с нулевым полезным выходом.
Они в основном там просят сделать возможным указывать в конфиге несколько директив ssl_stapling_file для ECDSA и RSA сертификатов. Но есть ведь и другие способы решения этой проблемы, например, чтобы nginx получал OCSP-ответ для сертификата с Must-Staple до того, как он отправит свой ответ клиенту. Пользователю ведь нет разницы, кто сходит за OCSP-ответом для сертификата - или браузер или сам веб-сервер.
Проблема для начала в том, что в OpenSSL нет возможности подождать получения OCSP-ответа, не блокируя рабочий процесс nginx'а.
Насколько я понимаю из исходников, nginx делает запрос к OCSP серверу самостоятельно, не блокируя рабочий процесс nginx'а. Очень похожий функционал запроса с "ожиданием" уже реализован в nginx, в директиве proxy_cache_lock - там ведь рабочий процесс не блокируется.
Я не считаю использование "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)" -- Best regards, Gena _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
