SSL Configuration Generator https://ssl-config.mozilla.org/

Илья Шипицин chipitsine на gmail.com
Пт Янв 10 13:03:14 UTC 2020


пт, 10 янв. 2020 г. в 16:53, Gena Makhomed <gmm на csdoc.com>:

> On 10.01.2020 8:41, Илья Шипицин wrote:
>
> >>> об этом кто угодно может завести баг
> >>> https://github.com/mozilla/ssl-config-generator
> >> В исходном моем сообщении как раз и содержится вопрос - баг это или нет.
> > в общем-то вы сами и ответили на свой вопрос.
>
> Я не уверен в том, что вижу и понимаю все нюансы.
>
> Поэтому мне очень хотелось бы, если это возможно, чтобы Maxim Dounin
> ответил на мои вопросы. По сути они были и есть адресованы
> в первую очередь именно ему.
>
> SSL Configuration Generator https://ssl-config.mozilla.org/
> - это наверное самый точный и самый популярный сайт, который
> публикует рекомендации по настройке SSL/TLS в nginx,
>

nginxconfig.io еще на слуху

есть пожелание ко всем этим конфигураторам - было логично, если давая
рекомендации, они бы давали примерную табличку
по браузерным хендшейкам типа "сделав такие то настройки, у вас будут
работать вот эти браузеры, и не будут вот эти"

сняло бы кучу вопросов


> поэтому было бы очень хорошо привести его рекомендации
> в соответствие с действительностью и сделать их максимально полезными.
>
> > в этом плане ssl labs в помощь. он дает просто отличную картину по
> эмуляции
> > клиентских хендшейков.
>
> Он не идеален и может ошибаться, в некоторых редких случаях.
> Тем более, что Ivan Ristić там уже не работает.
>

из имеющихся инструментов, тем не менее, это лучшее


>
> Уж простите за невольную рекламу (придется дать ссылку на отчет,
> чтобы было понятно о чем я говорю), вчера/сегодня буквально
> менял сертификаты на сайте и 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 и говорит (хотя ошибка, конечно,
высосана из пальца)




>
> Поддержка Namecheap.com объяснила, что вроде бы надо и таким образом
> для некоторых очень страых клиентов сайт будет нормально открываться
> а если сертификат USERTrust в bundle не включать то сайт не откроется.
>
> Хотя, может быть действительно нет смысла всем клиентам слать еще и
> сертификат USERTrust и достаточно будет только сертификата Sectigo?
>

наверное, вы не пробились до нужного уровня поддержки )) какое-то
беспомощное объяснение


>
> Чтобы довести до идеального состояния настройку SSL/TLS
> на этом сайте - необходимо будет перейти на CentOS 8,
> тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305.
>

нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на
более старых операционках.
они не будут задействованы, но и ошибки не будет.


>
> Все остальное - вроде бы уже сделано наиболее оптимальным способом?
>
> Фрагмент конфига:
>
>      ssl_protocols TLSv1.3 TLSv1.2;
>      ssl_prefer_server_ciphers off;
>

это спорная директива. есть мнение, что если ее задать как "on", то степень
контроля над выбранным сьютом выше, и это типа безопаснее.


>      ssl_ciphers
>
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
>
>      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_stapling on;
>      ssl_stapling_verify on;
>      resolver 127.0.0.1;
>
>      ssl_certificate
> /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.crt;
>      ssl_certificate_key
> /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.key;
>
>      ssl_certificate         /etc/tls/
> STAR.ideil.com/STAR.ideil.com.rsa.crt;
>      ssl_certificate_key     /etc/tls/
> STAR.ideil.com/STAR.ideil.com.rsa.key;
>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200110/276e08d6/attachment.htm>


Подробная информация о списке рассылки nginx-ru