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

Ср Янв 22 03:04:33 UTC 2020

On 10.01.2020 15:04, Maxim Dounin wrote:

>> Если создатели сайта https://ssl-config.mozilla.org/ ошибаются,
>> то осознать свою ошибку они смогут наверное только после того,
>> как им об этом напишет кто-то из разработчиков nginx?

> Нет, разработчики nginx тут ни при чём.  Тут вопрос исключительно
> в том, что именно хотят разрешить авторы конфигурации, а что -
> нет.  Они явно хотят разрешить DHE-шифры, и явно специально
> написали как директиву ssl_dhparam, так и
> DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 в списке
> шифров.
> 
> Возможно, тут дело в том, что предлагаемый список шифров -
> закрытый, и шифров без forward secrecy там вообще нет.  И
> соответственно DHE-шифры оставлены для того, чтобы какие-то
> соверменные, но малораспространённые клиенты без поддержки ECDH
> вообще хоть как-то могли коммуницировать с сервером.

Да, Вы правы.

Проблема есть с IE11 - по данным w3counter.com этот браузер имеет
2.30% Browser Market Share и вместе с тем, в случае использования
RSA сертификата, IE11 не умеет использовать ECDHE, и именно по этой
причине в списке шифров были оставлены DHE-шифры с RSA сертификатами.

Если же на сервере используется ECDSA сертификат - в таком случае
IE11 умеет использовать ECDHE, тогда нет никакой необходимости
использовать директиву ssl_dhparam и можно выключать все DHE-* шифры
и все *-RSA-* шифры в директиве ssl_ciphers, оставив там
только три самых нормальных ECDHE-ECDSA шифра
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
в режиме ssl_prefer_server_ciphers off;

0.
Кстати, причин, чтобы использвать ECDSA и RSA сертификаты одновременно
для сервера в котором разрешены только протоколы TLS 1.2 и TLS 1.3 -
я так и не смог найти. По всей видимости, одновременное использование
ECDSA и RSA сертификатов имеет смысл только для тех серверов, в которых
разрешено использование протоколов TLS 1.0 и TLS 1.1. Или я тут ошибся?

В багтрекере страницы https://wiki.mozilla.org/Security/Server_Side_TLS
а именно в issue https://github.com/mozilla/server-side-tls/issues/268
я немного пообщался теми людьми, которые редактируют эту вики страницу,
узнал от них много нового и интересного про причины, почему сайт
https://ssl-config.mozilla.org/ выдает именно такие рекомендации.

Сейчас готовлю сервер для тестирования скорости работы
ECDHE с различными вариантами ssl_ecdh_curve и ssl_ciphers
и DHE с различными вариантами ssl_dhparam и ssl_ciphers
и в процессе настройки nginx наткнулся на проблемы.

Параметры сборки nginx из исходников на CentOS 7:

# nginx -V
nginx version: nginx/1.17.8
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled
configure arguments: --with-http_ssl_module 
--with-openssl=/root/src/openssl-1.1.1d --with-pcre=/root/src/pcre-8.43 
--without-http_gzip_module

Проблемы:

1.
В документации
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
написано, что директиву ssl_protocols можно задавать на уровне server.

Однако - если в default_server было задано ssl_protocols TLSv1.2;
то в других server`ах директива ssl_protocols TLSv1.3; не работает.

И наоборот, если в default_server задано ssl_protocols TLSv1.3;
то в других server`ах директива ssl_protocols TLSv1.2; не работает.

Это где ошибка - в документации на сайте или в коде nginx 1.17.8?

2.
Аналогичная проблема и с директивой ssl_ecdh_curve:

В документации
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve
написано, что директиву ssl_ecdh_curve можно задавать на уровне server.

Однако, nginx на эту директиву вообще никак не реагирует.

У меня есть три тестовых сервера:

         server_name tls13-ecdsa-ecdhe-x25519.ideil.com;
         ssl_ecdh_curve X25519;

         server_name tls13-ecdsa-ecdhe-prime256v1.ideil.com;
         ssl_ecdh_curve prime256v1;

         server_name tls13-ecdsa-ecdhe-secp384r1.ideil.com;
         ssl_ecdh_curve secp384r1;

В действительности - везде используется X25519 для Server Temp Key.

Это где ошибка - в документации на сайте или в коде nginx 1.17.8?

3.
Третий вопрос, если можно:

Тикет https://trac.nginx.org/nginx/ticket/1529 читал
но по причине https://github.com/openssl/openssl/issues/7938
- что нам с этим всем делать? Как управлять ciphers в TLS 1.3 ?

Может быть все-таки имеет смысл сделать [недокументированную (?)]
директиву ssl_ciphersuites которая будет управлять шифрами для TLS 1.3 ?
Оставив директиву ssl_ciphers для управления шифрами TLS 1.2 и 1.1/1.0 ?

Чтобы можно было, например, для теста настроить все возможные комбинации
шифров TLS 1.3 (их всего три) и все возможные комбинации рекомендуемых
сайтом https://wiki.mozilla.org/Security/Server_Side_TLS вариантов
ecdh curve (их тоже всего три: X25519, prime256v1, secp384r1).
Итого - только для TLS 1.3 получается всего 9 возможных комбинаций.
Для всех возможных комбинаций - необходимо будет 36 различных серверов.

Кстати, google пошел еще дальше, и в конфигурации для www.google.com
сделал возможность отдельно настраивать значение директивы
ssl_prefer_server_ciphers и ssl_ciphers для TLS 1.3 и предыдущих версий.

https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com

Может быть и для nginx был бы приемлимым более обобщенный синтаксис,
например, что-то вроде такого:

ssl_ciphers TLSv1.3 ................;
ssl_ciphers TLSv1.2 ................;
ssl_ciphers TLSv1.1 ................;
ssl_ciphers TLSv1.0 ................;

ssl_prefer_server_ciphers TLSv1.3 off;
ssl_prefer_server_ciphers TLSv1.2 on;
ssl_prefer_server_ciphers TLSv1.1 on;
ssl_prefer_server_ciphers TLSv1.0 on;

?

-- 
Best regards,
  Gena