<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">вт, 11 сент. 2018 г. в 0:38, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10.09.2018 16:04, Maxim Dounin wrote:<br>
<br>
>> Если с помощью Let's Encrypt сделать SSL-сертификат<br>
>> для домена,например, <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> то в файле<br>
>> /etc/letsencrypt/live/<a href="http://example.com/README" rel="noreferrer" target="_blank">example.com/README</a><br>
>> будет такая информация:<br>
>><br>
>> `chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.<br>
>><br>
>> Чтобы nginx использовал файл chain.pem для OCSP stapling<br>
>> необходимо прописать в конфиге<br>
>><br>
>>    ssl_certificate /etc/letsencrypt/live/<a href="http://example.com/fullchain.pem" rel="noreferrer" target="_blank">example.com/fullchain.pem</a>;<br>
>>    ssl_certificate_key /etc/letsencrypt/live/<a href="http://example.com/privkey.pem" rel="noreferrer" target="_blank">example.com/privkey.pem</a>;<br>
>>    ssl_trusted_certificate /etc/letsencrypt/live/<a href="http://example.com/chain.pem" rel="noreferrer" target="_blank">example.com/chain.pem</a>;<br>
>><br>
>>    ssl_stapling on;<br>
>>    ssl_stapling_verify on;<br>
>>    resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off;<br>
>><br>
>> я правильно понимаю?<br>
<br>
> Just a side note: использование сторонних DNS-серверов - это<br>
> плохое решение.  Цитируя документацию:<br>
<br>
> : Для предотвращения DNS-спуфинга рекомендуется использовать<br>
> : DNS-серверы в защищённой доверенной локальной сети.<br>
<br>
Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing?<br>
<a href="https://en.wikipedia.org/wiki/DNS_spoofing" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/DNS_spoofing</a><br>
<br>
>> Смущает тот факт, что если закомментировать<br>
>> в конфиге директиву ssl_trusted_certificate<br>
>> - никаких предупреждений не выводится во время<br>
>> тестирования конфигурации и никаких сообщений<br>
>> не пишется в лог во время systemctl reload nginx<br>
<br>
> Верификация OCSP-ответов - происходит только в момент собственно<br>
> получения этих ответов.  Соответственно каких-либо ошибок в логе<br>
> стоит ожидать только после того, как к соответствующему server'у<br>
> будет установлено первое соединение с запросом stapling'а.<br>
<br>
Но если в конфиге нет директивы ssl_trusted_certificate то директива<br>
ssl_stapling_verify on; сейчас работать не сможет в 100% случаев?<br>
<br>
> Кроме того, в некоторых случаях для проверки может хватить<br>
> сертификатов, уже присутствующих в цепочке сертификата (по идее<br>
> должно хватать issuer cert, которые есть в цепочке почти всегда,<br>
> но, к сожалению, соответствующие функции в OpenSSL, cкажем так,<br>
> оставляют желать - и это, собственно, основная причина, почему<br>
> ssl_stapling_verify не используется по умолчанию).<br>
<br>
Но ведь SSL сертификаты - это обычные текстовые файлы.<br>
Например, если для сайта <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> сравнить два файла<br>
<br>
/etc/letsencrypt/live/<a href="http://example.com/fullchain.pem" rel="noreferrer" target="_blank">example.com/fullchain.pem</a><br>
/etc/letsencrypt/live/<a href="http://example.com/chain.pem" rel="noreferrer" target="_blank">example.com/chain.pem</a><br>
<br>
то видно что файл chain.pem равен файлу fullchain.pem<br>
плюс дополнительный сертификат сайта на самом верху.<br>
<br>
Можно ли сделать для директивы ssl_trusted_certificate параметр auto<br>
который будет означать автоматическое получение файла chain.pem путем<br>
вырезания самого первого сертификата из файла fullchain.pem?<br>
<br>
В таком случае можно было бы сделать значением по-умолчанию<br>
ssl_trusted_certificate auto; и ssl_stapling_verify on;<br>
И веб-сервер nginx тогда будет "Secure by default".<br>
<br>
Хотя, проверка клиентских сертификатов и проверка ответов OCSP<br>
- это две совсем разные задачи, странно что для них используется<br>
в nginx одна и та же директива ssl_trusted_certificate.<br>
<br>
Не лучше ли было бы для этих двух разных задач<br>
иметь и две разные директивы?<br>
<br>
Например,<br>
ssl_trusted_certificate - только для проверки клиентских сертификатов<br>
и ssl_stapling_trusted_certificate - только для проверки ответов OCSP<br>
<br>
и уже для директивы ssl_stapling_trusted_certificate<br>
сделать значение по-умолчанию равное auto?<br>
<br>
IMHO это был бы практически идеальный вариант,<br>
поскольку будет работать предсказуемым образом<br>
вне зависимости от имени и версии используемой<br>
при сборке nginx SSL-библиотеки.<br>
<br>
>> Насколько я понимаю, ssl_stapling_verify on<br>
>> следует включать всегда, потому что общение<br>
>> с OCSP сервером происходит по протоколу HTTP?<br>
>> По крайней мере, в самом сертификате написано:<br>
>> OCSP: URI: <a href="http://ocsp.int-x3.letsencrypt.org" rel="noreferrer" target="_blank">http://ocsp.int-x3.letsencrypt.org</a><br>
<br>
> Да, общение с OCSP-сервером происходит по HTTP.  Но на самом деле<br>
> это мало влияет на то, следует ли использовать ssl_stapling_verify<br>
> или нет - самому nginx'у всё равно, что написано в OCSP-ответе.<br>
> Вопрос в первую очередь в поведении браузеров.<br>
<br>
> Когда я последний углублялся в тему - Firefox остро реагировал на<br>
> некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно<br>
> перезапросить OCSP-ответ с OCSP-сервера, и это естественным<br>
> образом приводило к тому, что подсунув серверу некорректный<br>
> OCSP-ответ - можно было выключить его для всех пользователей<br>
> Firefox'а[1].  Что, впрочем, не мешало Apache не иметь даже<br>
> возможности для верификации OCSP-ответов.  Не в курсе, изменилось<br>
> ли с тех пор что-нибудь.<br>
> <br>
> [1] <a href="https://trac.nginx.org/nginx/ticket/425#comment:2" rel="noreferrer" target="_blank">https://trac.nginx.org/nginx/ticket/425#comment:2</a><br>
<br>
То есть, ssl_stapling_verify on; в nginx следует включать всегда<br>
и нет никаких разумных причин, почему системный администратор<br>
может захотеть сделать ssl_stapling_verify off; для своего сайта?<br></blockquote><div><br></div><div>у клиентов может быть неправильное время (например, они так могут делать при вводе документов в 1С)</div><div>если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат невалиден, и почему-то</div><div>браузеры так запрограммированы, что кнопки "игнорировать, покажите мне уже сайт" у клиента не будет.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Best regards,<br>
  Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>