<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 10 янв. 2020 г. в 22:00, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10.01.2020 15:03, Илья Шипицин wrote:<br>
<br>
> <a href="http://nginxconfig.io" rel="noreferrer" target="_blank">nginxconfig.io</a> еще на слуху<br>
<br>
этот сайт не открывается, ERR_CONNECTION_REFUSED.<br>
<br>
> есть пожелание ко всем этим конфигураторам - было логично, если давая<br>
> рекомендации, они бы давали примерную табличку<br>
> по браузерным хендшейкам типа "сделав такие то настройки, у вас будут<br>
> работать вот эти браузеры, и не будут вот эти"<br>
> <br>
> сняло бы кучу вопросов<br>
<br>
Вряд ли создатели сайта <a href="https://ssl-config.mozilla.org/" rel="noreferrer" target="_blank">https://ssl-config.mozilla.org/</a><br>
читают этот список рассылки. Наверное Вам имеет смысл обратиться<br>
к ним напрямую - <a href="https://github.com/mozilla/ssl-config-generator/issues" rel="noreferrer" target="_blank">https://github.com/mozilla/ssl-config-generator/issues</a><br>
<br>
Идея, которую Вы озвучили действительно очень толковая,<br>
и было бы замечательно, если бы они смогли ее реализовать.<br></blockquote><div><br></div><div><br></div><div><a href="https://github.com/mozilla/ssl-config-generator/issues/73">https://github.com/mozilla/ssl-config-generator/issues/73</a></div><div><br></div><div>в каком отделении счет открывали, туда и идите.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>> Уж простите за невольную рекламу (придется дать ссылку на отчет,<br>
>> чтобы было понятно о чем я говорю), вчера/сегодня буквально<br>
>> менял сертификаты на сайте и ssltest выдал мне такое предупреждение:<br>
>><br>
>> <a href="https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com" rel="noreferrer" target="_blank">https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com</a><br>
>><br>
>> Chain issues    Contains anchor<br>
>><br>
>> Подробное обсуждение этого предупреждения есть на странице<br>
>> <a href="https://discussions.qualys.com/thread/11234" rel="noreferrer" target="_blank">https://discussions.qualys.com/thread/11234</a><br>
>><br>
>> Где Ivan Ristić рекомендует спросить у поддержки Namecheap.com<br>
>> зачем они рекмендуют включать CA сертификат USERTrust в bundle.<br>
> <br>
> наличие корневого серта в цепочке имеет некий смысл. реальный кейс - смена<br>
> корня у Thawte с MD5 на SHA1<br>
> вы получили новый сертификат на новом SHA1 корне. всё отлично кроме того,<br>
> что у кучи необновленных клиентов этого корня еще нет.<br>
> <br>
> для этого Thawte отдавал вам кросс-подпись с корня MD5 на новый корень.<br>
> <br>
> и вы могли, отдавая цепочку "кросс + новый корень + промежуточный + сервер"<br>
> попасть в область доверия необновленных клиентов.<br>
> это прямо реально работало. отдавать только корень без кросса смысла нет,<br>
> более того, различный софт наличие самоподписанного серта в отдаваемой<br>
> цепочке<br>
> будет считать ошибкой, о чем вам ssl labs и говорит (хотя ошибка, конечно,<br>
> высосана из пальца)<br>
<br>
Нсколько я понял Ваше объяснение и слова Ivan Ristić на странице<br>
<a href="https://discussions.qualys.com/thread/11234" rel="noreferrer" target="_blank">https://discussions.qualys.com/thread/11234</a> о том,<br>
что "There won't be any side effects if you remove the self-signed<br>
roots. They wouldn't be used anyhow" - самоподписанный корневой<br>
сертификат USERTrust RSA Certification Authority из цепочки<br>
лучше убрать, потому что толку от него вообще никакого не будет,<br>
это только лишние данные по сети передаются, пустая трата ресурсов.<br>
<br>
Дополнительная полезная информация есть на сайте sectigo на странице<br>
<a href="https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ" rel="noreferrer" target="_blank">https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ</a><br>
<br>
Self-signed Сертификат USERTrust RSA Certification Authority (Root CA)<br>
был создан в 2010 году и действителен до 2038 года. Поскольку я на<br>
сервере выключаю поддержку TLS 1.0 и TLS 1.1 - более старые клиенты<br>
всё равно работать не будут и поддерживать мне их не нужно,<br>
а у более новых клиентов этот сертификат и так уже находится<br>
в их локальном trust store.<br>
<br>
Другой Trust Chain Path, в котором сертификат<br>
USERTrust RSA Certification Authority является промежуточным,<br>
и подписан корневым сертификатом AddTrust External CA Root<br>
рассматривать смысла не имеет, потому что сертификат<br>
AddTrust External CA Root действителен только до 30 мая 2020 года.<br>
А также потому что этот Trust Chain Path был нужен только для тех<br>
очень старых клиентов, которые имели в своем trust store сертификат<br>
AddTrust External CA Root, выпущенный в 2000 году,<br>
но не имели сертификата USERTrust RSA Certification Authority,<br>
который был выпущен в 2010 году.<br>
<br>
Так что Ivan Ristić все-таки был прав,<br>
и созданный им сайт <a href="https://www.ssllabs.com/ssltest/" rel="noreferrer" target="_blank">https://www.ssllabs.com/ssltest/</a><br>
выдает очень толковые предупреждения и рекомендации.<br>
<br>
Спасибо, что помогли мне разобраться в этой ситуации.<br>
Теперь, вроде бы все стало ясно и понятно по этому вопросу.<br>
<br>
>> Чтобы довести до идеального состояния настройку SSL/TLS<br>
>> на этом сайте - необходимо будет перейти на CentOS 8,<br>
>> тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305.<br>
<br>
> нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на<br>
> более старых операционках. они не будут задействованы, но и ошибки не будет.<br>
<br>
Верно.<br>
<br>
Именно так я и поступил - в настройках nginx сейчас включены<br>
и TLS1.3 и ChaCha20-Poly1305, но активными эти настройки<br>
станут только в том случае, когда я перенесу сайт на сервер<br>
с CentOS 8, где будет стоять более новая версия OpenSSL 1.1.1<br>
<br>
>>       ssl_prefer_server_ciphers off;<br>
<br>
> это спорная директива. есть мнение, что если ее задать как "on", то степень<br>
> контроля над выбранным сьютом выше, и это типа безопаснее.<br>
<br>
Есть мнение, что это ошибочное мнение.<br>
<br>
Я общался на эту тему с Maxim Dounin. И он еще несколько лет тому назад<br>
говорил, что лучше будет, если ssl_prefer_server_ciphers оставить<br>
в выключенном состоянии.<br>
<br>
Почему? Потому что какой именно шифр будет работать наиболее <br>
производительным образом на каждом конкретном клиенте -<br>
это может знать только сам этот клиент, но никак не сервер.<br>
<br>
Например, на мобильных устройствах и на компьютерах с процессорами<br>
без поддержки AES-NI шифр ChaCha20/Poly1305 будет более быстрым.<br>
<br>
Но на компьютерах с поддержкой AES-NI - шифры AES-128 и AES-256<br>
будут работать быстрее, чем ChaCha20/Poly1305.<br>
<br>
Подробнее - см. например картинку<br>
<a href="https://hsto.org/files/2ac/5d2/128/2ac5d212814145acae1975a9e104bb93.png" rel="noreferrer" target="_blank">https://hsto.org/files/2ac/5d2/128/2ac5d212814145acae1975a9e104bb93.png</a><br>
из статьи <a href="https://habr.com/ru/post/325230/" rel="noreferrer" target="_blank">https://habr.com/ru/post/325230/</a> (сама эта статья во многом<br>
уже морально устарела и выдает некорректные на сегодня рекомендации,<br>
но некоторая полезная информация в ней всё равно содержится)<br>
<br>
Исходники десктопных браузеров Chrome/Firefox и мобильных браузеров<br>
я не смотрел, но очень надеюсь на то, что они умеют самостоятельно<br>
корректно выбирать наиболее быстрый шифр. По крайней мере,<br>
если они вдруг этого еще не умеют - их можно будет этому<br>
достаточно быстро научить.<br>
<br>
Делать ssl_prefer_server_ciphers on; имеет смысл только в том случае,<br>
когда в каких-то шифрах обнаружена уязвимость, и часть клиентов<br>
еще не обновилась, тогда можно с помощью этой настройки опускать<br>
до нуля приоритет уязвимых шифров, выводя в начало списка безопасные.<br>
<br>
Других причин крутить настройку ssl_prefer_server_ciphers я не вижу.<br>
И Maxim Dounin тоже не видит, если я правильно понял и помню его слова.<br>
<br>
По крайней мере, на сегодняшний день, когда подавляющее большинство <br>
клиентов умеют TLS 1.2 - в большинстве случаев использовать устаревшие<br>
версии протокола и/или устаревшие/уязвимые шифры смысла никакого нет.<br>
Соответственно, поэтому же и нет смысла в ssl_prefer_server_ciphers on;<br>
<br>
>> ssl_session_cache shared:SSL:10M;<br>
>> ssl_session_timeout 120m;<br>
<br>
> ssl_session с каким-то завидным упорством все тащат в конфиг.<br>
> на самом деле это устаревший механизм по отношению к<br>
> <br>
> <a href="https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key" rel="noreferrer" target="_blank">https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key</a><br>
> <br>
> ticket-ы работают так же, с тем исключением, что они хранятся на стороне клиента.<br>
<br>
По умолчанию ssl_session_tickets on; значение этой директивы я не менял.<br>
<br>
Вы видите какой-то смысл в том, чтобы выключать ssl_session_cache<br>
для экономии на сервере нескольких мегабайт shared memory?<br>
<br>
Вы думали о том, что будет в той ситуации, когда ssl_session_cache<br>
выключен, а клиент по какой-то причине не поддерживает ticket-ы?<br>
<br>
> является хорошей практикой указывать файл с настройками тикетов.<br>
<br>
Есть такое мнение, что это является очень плохой практикой.<br>
<br>
<a href="https://www.imperialviolet.org/2013/06/27/botchingpfs.html" rel="noreferrer" target="_blank">https://www.imperialviolet.org/2013/06/27/botchingpfs.html</a><br>
How to botch TLS forward secrecy<br>
<br>
В документации к nginx же написано, что директива ssl_session_ticket_key<br>
необходима, если один и тот же ключ нужно использовать на нескольких <br>
серверах. В остальных случаях - случайно сгенерированный ключ, который <br>
хранится в памяти nginx будет гораздо лучше как с точки зрения<br>
безопасности, так и с точки зрения удобства администрирования.<br>
<br>
Вот и здесь: <a href="https://github.com/mozilla/server-side-tls/issues/135" rel="noreferrer" target="_blank">https://github.com/mozilla/server-side-tls/issues/135</a><br>
и здесь тоже <a href="https://github.com/mozilla/ssl-config-generator/issues/69" rel="noreferrer" target="_blank">https://github.com/mozilla/ssl-config-generator/issues/69</a><br>
вообще рекомендуется ssl_session_tickets off; потому что proper rotation<br>
of session ticket encryption key is not implemented in nignx.<br>
<br>
То же самое выдает сейчас и сайт <a href="https://ssl-config.mozilla.org" rel="noreferrer" target="_blank">https://ssl-config.mozilla.org</a><br>
для Modern варианта конфигурации (Services with clients<br>
that support TLS 1.3 and don't need backward compatibility)<br>
<br>
И логика в этом есть, лучше уж выключить ssl_session_tickets,<br>
чем потерять Forward Secrecy. Многим пользователям безопасность<br>
HTTPS подключений важнее повышения производительности работы сервера.<br>
<br>
> в противном случае на релоаде<br>
> старые тикеты обнуляются, и у вас может быть всплеск нагрузки (из-за<br>
> пересогласования хендшейков)<br>
<br>
Лучше уж пусть будет всплеск нагрузки, чем ssl_session_ticket_key,<br>
который не меняется годами и который сводит Forward Secrecy к нулю.<br>
<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>