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; для своего сайта?
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
