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

[Gena Makhomed]

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

Идея, которую Вы озвучили действительно очень толковая,
и было бы замечательно, если бы они смогли ее реализовать.

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