Hello! On Wed, Sep 19, 2018 at 12:26:01AM +0300, Gena Makhomed wrote:
> 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? Всё так, именно этой цели соответствует решение "must staple". Проблема тут во многом - в целеполагании. [...] > >> Они в основном там просят сделать возможным указывать в конфиге > >> несколько директив 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-серверу, чтобы этот ответ получить для последующих клиентов. > > Я не считаю использование "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". Попытки же изобретать сложную логику - "здесь играем, здесь не играем, здесь рыбу заворачивали" - выглядят, скажем мягко, странно. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
