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 mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru