OCSP stapling in Nginx >=1.3.7

Пн Сен 10 20:22:33 UTC 2018

вт, 11 сент. 2018 г. в 0:38, Gena Makhomed <gmm на csdoc.com>:

> On 10.09.2018 16:04, Maxim Dounin wrote:
>
> >> Если с помощью Let's Encrypt сделать SSL-сертификат
> >> для домена,например, example.com то в файле
> >> /etc/letsencrypt/live/example.com/README
> >> будет такая информация:
> >>
> >> `chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
> >>
> >> Чтобы nginx использовал файл chain.pem для OCSP stapling
> >> необходимо прописать в конфиге
> >>
> >>    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
> >>    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
> >>    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
> >>
> >>    ssl_stapling on;
> >>    ssl_stapling_verify on;
> >>    resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off;
> >>
> >> я правильно понимаю?
>
> > Just a side note: использование сторонних DNS-серверов - это
> > плохое решение.  Цитируя документацию:
>
> > : Для предотвращения DNS-спуфинга рекомендуется использовать
> > : DNS-серверы в защищённой доверенной локальной сети.
>
> Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing?
> https://en.wikipedia.org/wiki/DNS_spoofing
>
> >> Смущает тот факт, что если закомментировать
> >> в конфиге директиву ssl_trusted_certificate
> >> - никаких предупреждений не выводится во время
> >> тестирования конфигурации и никаких сообщений
> >> не пишется в лог во время systemctl reload nginx
>
> > Верификация OCSP-ответов - происходит только в момент собственно
> > получения этих ответов.  Соответственно каких-либо ошибок в логе
> > стоит ожидать только после того, как к соответствующему server'у
> > будет установлено первое соединение с запросом stapling'а.
>
> Но если в конфиге нет директивы ssl_trusted_certificate то директива
> ssl_stapling_verify on; сейчас работать не сможет в 100% случаев?
>
> > Кроме того, в некоторых случаях для проверки может хватить
> > сертификатов, уже присутствующих в цепочке сертификата (по идее
> > должно хватать issuer cert, которые есть в цепочке почти всегда,
> > но, к сожалению, соответствующие функции в OpenSSL, cкажем так,
> > оставляют желать - и это, собственно, основная причина, почему
> > ssl_stapling_verify не используется по умолчанию).
>
> Но ведь SSL сертификаты - это обычные текстовые файлы.
> Например, если для сайта example.com сравнить два файла
>
> /etc/letsencrypt/live/example.com/fullchain.pem
> /etc/letsencrypt/live/example.com/chain.pem
>
> то видно что файл chain.pem равен файлу fullchain.pem
> плюс дополнительный сертификат сайта на самом верху.
>
> Можно ли сделать для директивы ssl_trusted_certificate параметр auto
> который будет означать автоматическое получение файла chain.pem путем
> вырезания самого первого сертификата из файла fullchain.pem?
>
> В таком случае можно было бы сделать значением по-умолчанию
> ssl_trusted_certificate auto; и ssl_stapling_verify on;
> И веб-сервер nginx тогда будет "Secure by default".
>
> Хотя, проверка клиентских сертификатов и проверка ответов OCSP
> - это две совсем разные задачи, странно что для них используется
> в nginx одна и та же директива ssl_trusted_certificate.
>
> Не лучше ли было бы для этих двух разных задач
> иметь и две разные директивы?
>
> Например,
> ssl_trusted_certificate - только для проверки клиентских сертификатов
> и ssl_stapling_trusted_certificate - только для проверки ответов OCSP
>
> и уже для директивы ssl_stapling_trusted_certificate
> сделать значение по-умолчанию равное auto?
>
> IMHO это был бы практически идеальный вариант,
> поскольку будет работать предсказуемым образом
> вне зависимости от имени и версии используемой
> при сборке nginx SSL-библиотеки.
>
> >> Насколько я понимаю, ssl_stapling_verify on
> >> следует включать всегда, потому что общение
> >> с OCSP сервером происходит по протоколу HTTP?
> >> По крайней мере, в самом сертификате написано:
> >> OCSP: URI: http://ocsp.int-x3.letsencrypt.org
>
> > Да, общение с OCSP-сервером происходит по HTTP.  Но на самом деле
> > это мало влияет на то, следует ли использовать ssl_stapling_verify
> > или нет - самому nginx'у всё равно, что написано в OCSP-ответе.
> > Вопрос в первую очередь в поведении браузеров.
>
> > Когда я последний углублялся в тему - Firefox остро реагировал на
> > некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно
> > перезапросить OCSP-ответ с OCSP-сервера, и это естественным
> > образом приводило к тому, что подсунув серверу некорректный
> > OCSP-ответ - можно было выключить его для всех пользователей
> > Firefox'а[1].  Что, впрочем, не мешало Apache не иметь даже
> > возможности для верификации OCSP-ответов.  Не в курсе, изменилось
> > ли с тех пор что-нибудь.
> >
> > [1] https://trac.nginx.org/nginx/ticket/425#comment:2
>
> То есть, ssl_stapling_verify on; в nginx следует включать всегда
> и нет никаких разумных причин, почему системный администратор
> может захотеть сделать ssl_stapling_verify off; для своего сайта?
>

у клиентов может быть неправильное время (например, они так могут делать
при вводе документов в 1С)
если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат
невалиден, и почему-то
браузеры так запрограммированы, что кнопки "игнорировать, покажите мне уже
сайт" у клиента не будет.

>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180911/a8f33900/attachment-0001.html>