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