OCSP stapling in Nginx >=1.3.7

Maxim Dounin mdounin на mdounin.ru
Вт Сен 11 03:21:09 UTC 2018


Hello!

On Mon, Sep 10, 2018 at 10:38:25PM +0300, Gena Makhomed wrote:

> 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

Речь не о том, подвержены ли эти сервера атакам.  Речь о том, что 
при использовании не-локальных DNS-серверов в некотороых случаях 
становятся возможны атаки на resolver nginx'а, так как он общается 
с удалённым DNS-сервером - то есть, фактически, открыт для всего 
мира с точностью до номера порта и 16-битного query id, ибо 
spoofing IP-адреса в UDP-пакетах проблемы не представляет.

> >> Смущает тот факт, что если закомментировать
> >> в конфиге директиву ssl_trusted_certificate
> >> - никаких предупреждений не выводится во время
> >> тестирования конфигурации и никаких сообщений
> >> не пишется в лог во время systemctl reload nginx
> 
> > Верификация OCSP-ответов - происходит только в момент собственно
> > получения этих ответов.  Соответственно каких-либо ошибок в логе
> > стоит ожидать только после того, как к соответствующему server'у
> > будет установлено первое соединение с запросом stapling'а.
> 
> Но если в конфиге нет директивы ssl_trusted_certificate то директива
> ssl_stapling_verify on; сейчас работать не сможет в 100% случаев?

Зависит от того, каким сертификатом подписан OCSP-ответ, и 
какие именно сертификаты лежал в цепочке в ssl_certificate.

> > Кроме того, в некоторых случаях для проверки может хватить
> > сертификатов, уже присутствующих в цепочке сертификата (по идее
> > должно хватать 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.
> 
> Не лучше ли было бы для этих двух разных задач
> иметь и две разные директивы?

Лучше всего - сделать так, чтобы OpenSSL научился проверять 
OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного 
root'а, а ровно так, как и должно быть по стандарту - с помощью 
одного только сертификата issuer'а.  Тогда проблема исчезнет.

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

[...]

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


Подробная информация о списке рассылки nginx-ru