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