ср, 19 сент. 2018 г. в 2:26, Gena Makhomed <gmm@csdoc.com>:

> 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?
>


SSL соединение может быть установлено, если сервер использует

а) действующий сертификат (на текущий момент времени)
б) сертификат серверного типа
в) сертификат не отозван (это можно проверить через CRL)


это, собственно, "другие" методы. известные еще нашим отцам и дедам.
но исторически в части CRL все работало не очень стабильно, и браузеры
де факто
не делают проблемы, если не могут скачать CRL

вероятно, они так же не будут делать проблемы с сертами 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
>
> Теперь понял, спасибо за подробное объяснение по этому вопросу.
>


на Xeon chacha20 проигрывает, мы сравнили

openssl speed -evp chacha20

с

openssl speed -evp aes-128-gcm

желание приоритезировать chacha20 отпало


>
> Кстати, в веб-сервере 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
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru