<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 10 янв. 2020 г. в 16:53, 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 8:41, Илья Шипицин wrote:<br>
<br>
>>> об этом кто угодно может завести баг<br>
>>> <a href="https://github.com/mozilla/ssl-config-generator" rel="noreferrer" target="_blank">https://github.com/mozilla/ssl-config-generator</a><br>
>> В исходном моем сообщении как раз и содержится вопрос - баг это или нет.<br>
> в общем-то вы сами и ответили на свой вопрос.<br>
<br>
Я не уверен в том, что вижу и понимаю все нюансы.<br>
<br>
Поэтому мне очень хотелось бы, если это возможно, чтобы Maxim Dounin <br>
ответил на мои вопросы. По сути они были и есть адресованы<br>
в первую очередь именно ему.<br>
<br>
SSL Configuration Generator <a href="https://ssl-config.mozilla.org/" rel="noreferrer" target="_blank">https://ssl-config.mozilla.org/</a><br>
- это наверное самый точный и самый популярный сайт, который<br>
публикует рекомендации по настройке SSL/TLS в nginx,<br></blockquote><div><br></div><div><a href="http://nginxconfig.io">nginxconfig.io</a> еще на слуху</div><div><br></div><div>есть пожелание ко всем этим конфигураторам - было логично, если давая рекомендации, они бы давали примерную табличку</div><div>по браузерным хендшейкам типа "сделав такие то настройки, у вас будут работать вот эти браузеры, и не будут вот эти"</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>
> в этом плане ssl labs в помощь. он дает просто отличную картину по эмуляции<br>
> клиентских хендшейков.<br>
<br>
Он не идеален и может ошибаться, в некоторых редких случаях.<br>
Тем более, что Ivan Ristić там уже не работает.<br></blockquote><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></blockquote><div><br></div><div><br></div><div>наличие корневого серта в цепочке имеет некий смысл. реальный кейс - смена корня у Thawte с MD5 на SHA1</div><div>вы получили новый сертификат на новом SHA1 корне. всё отлично кроме того, что у кучи необновленных клиентов этого корня еще нет.</div><div><br></div><div>для этого Thawte отдавал вам кросс-подпись с корня MD5 на новый корень.</div><div><br></div><div>и вы могли, отдавая цепочку "кросс + новый корень + промежуточный + сервер" попасть в область доверия необновленных клиентов.</div><div>это прямо реально работало. отдавать только корень без кросса смысла нет, более того, различный софт наличие самоподписанного серта в отдаваемой цепочке <br></div><div>будет считать ошибкой, о чем вам ssl labs и говорит (хотя ошибка, конечно, высосана из пальца)<br></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>
Поддержка Namecheap.com объяснила, что вроде бы надо и таким образом<br>
для некоторых очень страых клиентов сайт будет нормально открываться<br>
а если сертификат USERTrust в bundle не включать то сайт не откроется.<br>
<br>
Хотя, может быть действительно нет смысла всем клиентам слать еще и<br>
сертификат USERTrust и достаточно будет только сертификата Sectigo?<br></blockquote><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>
Чтобы довести до идеального состояния настройку SSL/TLS<br>
на этом сайте - необходимо будет перейти на CentOS 8,<br>
тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305.<br></blockquote><div><br></div><div>нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на более старых операционках.</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>
Фрагмент конфига:<br>
<br>
     ssl_protocols TLSv1.3 TLSv1.2;<br>
     ssl_prefer_server_ciphers off;<br></blockquote><div><br></div><div>это спорная директива. есть мнение, что если ее задать как "on", то степень контроля над выбранным сьютом выше, и это типа безопаснее.<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">
     ssl_ciphers <br>
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;<br>
<br>
     ssl_session_cache shared:SSL:10M;<br>
     ssl_session_timeout 120m;<br></blockquote><div><br></div><div>ssl_session с каким-то завидным упорством все тащат в конфиг.</div><div>на самом деле это устаревший механизм по отношению к <br></div><div><br></div><div><a href="https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key">https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key</a></div><div><br></div><div>ticket-ы работают так же, с тем исключением, что они хранятся на стороне клиента.</div><div>является хорошей практикой указывать файл с настройками тикетов. в противном случае на релоаде</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>
     ssl_stapling on;<br>
     ssl_stapling_verify on;<br>
     resolver 127.0.0.1;<br>
<br>
     ssl_certificate <br>
/etc/tls/<a href="http://STAR.ideil.com/STAR.ideil.com.ecdsa.crt" rel="noreferrer" target="_blank">STAR.ideil.com/STAR.ideil.com.ecdsa.crt</a>;<br>
     ssl_certificate_key <br>
/etc/tls/<a href="http://STAR.ideil.com/STAR.ideil.com.ecdsa.key" rel="noreferrer" target="_blank">STAR.ideil.com/STAR.ideil.com.ecdsa.key</a>;<br>
<br>
     ssl_certificate         /etc/tls/<a href="http://STAR.ideil.com/STAR.ideil.com.rsa.crt" rel="noreferrer" target="_blank">STAR.ideil.com/STAR.ideil.com.rsa.crt</a>;<br>
     ssl_certificate_key     /etc/tls/<a href="http://STAR.ideil.com/STAR.ideil.com.rsa.key" rel="noreferrer" target="_blank">STAR.ideil.com/STAR.ideil.com.rsa.key</a>;<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>