OCSP stapling in Nginx >=1.3.7

[Maxim Dounin]

Hello!

On Tue, Sep 18, 2018 at 05:01:07PM +0300, Gena Makhomed wrote:

> On 17.09.2018 2:36, Maxim Dounin wrote:
> 
> >>>>>>>>> Лучше всего - сделать так, чтобы OpenSSL научился проверять
> >>>>>>>>> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного
> >>>>>>>>> root'а, а ровно так, как и должно быть по стандарту - с помощью
> >>>>>>>>> одного только сертификата issuer'а. Тогда проблема исчезнет.
> 
> Над OCSP в OpenSSL работал Rob Stradling из Comodo, может быть имеет
> смысл к нему обратиться с просьбой исправить эту проблему в OpenSSL?

Rob точно учавствовал в обсуждениях, где проблема излагалась, и 
даже, помнится, пытался что-то править.

> >> Кстати, пользователи жалуются, что есть 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.

Проблема в том, что нельзя просто так взять механизм оптимизации и 
сделать из него механизм контроля, это две разные задачи, которые 
надо решать по-разному.

> Кстати, тест на ssllabs.com показывает OCSP Must-Staple зеленым цветом.
> Ivan Ristic как бы намекает, что это полезный флаг и его стоит включить.
> 
> > Любители 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-ответом для сертификата - или браузер или сам веб-сервер.
> 
> Разумеется, не отправлять ответ клиенту без OCSP Stapling'а имеет смысл
> только для тех сертификатов, у которых установлен флаг OCSP Must-Staple.

Проблема для начала в том, что в OpenSSL нет возможности подождать 
получения OCSP-ответа, не блокируя рабочий процесс nginx'а. 

> P.S.
> 
> Кстати, если посмотреть через https://www.ssllabs.com/ssltest/
> на сайты nginx.org и nginx.com, то видно, что с nginx.org все
> нормально, а вот nginx.com настроен не совсем оптимально.
> 
> Наверное самый простой вариант корректной настройки сервера:
> 
>      # OpenSSL, ssl_ciphers и nginx: прокачиваем на 100%
>      # https://habrahabr.ru/post/325230/
> 
>      ssl_prefer_server_ciphers on;
>      ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1;
>      ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;
> 
> Может быть имеет смысл сделать эти значения
> значениями по-умолчанию в nginx?

Я не считаю использование "ssl_prefer_server_ciphers on" 
правильным приблизительно нигде, кроме ситуаций, когда автор 
конфигурации чётко понимает, чего он хочет добиться, и регулярно 
занимается анализом и пересмотром списка используемых шифров.

И даже в этом случае - его использование подчас выходит боком, как 
например с выбором AES vs. ChaCha20: 

https://trac.nginx.org/nginx/ticket/1445

Во всех остальных случаях - значение "ssl_prefer_server_ciphers 
off;", используемое по умолчанию, является лучшим выбором, так как 
позволяет клиенту самому выбрать, какой шифр для него лучше.

Текущие значения по умолчанию - "ssl_prefer_server_ciphers off;" и 
"ssl_ciphers HIGH:!aNULL:!MD5;" - позволяют получить наилучшую 
работу SSL с минимальными усилиями.

Что до "не совсем оптимально", то рекомендую внимательно 
посмотреть, на что именно жалуется ssllabs в данном случае.  Он 
жалуется на то, что на практике не будет Forward Secrecy со 
следующими браузерами:

IE 7 / Vista
IE 10 / Win Phone 8.0
IE 11 / Win Phone 8.1 

То есть речь идёт про старые версии IE на неподдерживаемых 
операционных системах.  При том, что общая доля IE сейчас ~3%.  
Подозреваю, что у тех, кто всё ещё пользуется этими браузерами - 
если такие люди ещё действительно остались - есть проблемы 
серьёзнее, чем отсутствие Forward Secrecy.

-- 
Maxim Dounin
http://mdounin.ru/