пт, 10 янв. 2020 г. в 22:00, Gena Makhomed <gmm@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