Идеальный результат SSL Labs с nginx и TLS 1.3?
Я создал конфигурацию nginx, которая получила высшую оценку в Qualsys SSL Labs, используя только TLS v1.2, и я хотел бы попытаться получить высшую оценку, используя как TLS v1.2, так и v1.3.
Рассмотрим этот фрагмент версии nginx.conf, который является частью оценки A + и 100%:
ssl_protocols TLSv1.2;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
Он жалуется на пару комплектов шифров, но все равно дает высший балл:
Теперь, если я добавлю к смеси TLS v1.3 в качестве только изменение конфигурации, оценка меняется.
ssl_protocols TLSv1.2 TLSv1.3;
Надежность шифра оценивается как 90%: 
Я полагаю, он без ума от этих слабых шифров CBC:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits FS WEAK
На самом деле нет хорошего способа полностью удалить шифры режима CBC, но, возможно, исключение SHA1, SHA256 и SHA384 будет работать. Строка конфигурации становится такой:
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL:!SHA1:!SHA256:!SHA384;
Посмотрим на новую оценку: 
Надежность шифров по-прежнему составляет 90%.
Больше не злится на мощь наборов шифров: 
Но, видимо, он недоволен неудачными рукопожатиями, которые работали раньше: 
Это подводит нас к ... те же наборы шифров, которые требуются для успешного рукопожатия для старых устройств / приложений, указаны как «слабые» и проходят, если включен только TLS 1.2. Каким-то образом включение TLS 1.3 делает те же самые слабые шифры, которые проходят до начала сбоя.
Вроде выбор такой: либо включить TLS 1.2 только получить наивысший балл или включить TLS 1.3, но при этом отказаться от необходимых наборов шифров? Это Кобаяши Мару своего рода.
Можно ли получить идеальный 100% результат при включенных nginx и TLS 1.2 и 1.3?
Что касается вашего фактического вопроса, который касается Qualys SSL Labs тестовый инструмент, нам нужно будет разобраться, как работает их рейтинговая система.
К счастью, Qualys опубликовали свои Руководство по оценке SSL-сервера, в котором описывается их методология оценки конфигураций SSL / TLS.
Поскольку ваш вопрос касается того, почему у вас немного ниже балл в Категория надежности шифра с одной из предложенных вами конфигураций над другой, давайте сосредоточимся конкретно на этой категории:
Cipher Strength
Чтобы прервать сеанс связи, злоумышленник может попытаться взломать симметричный шифр, используемый для основной части сеанса связи. Более сильный шифр обеспечивает более надежное шифрование и, следовательно, увеличивает усилия, необходимые для его взлома. Поскольку сервер может поддерживать шифры разной силы, мы пришли к системе подсчета очков, которая наказывает использование слабых шифров. Чтобы рассчитать оценку для этой категории, мы следуем следующему алгоритму:
- Начните со счета самого надежного шифра.
- Добавьте оценку самого слабого шифра.
- Разделите сумму на 2.
Таблица 5. Руководство по оценке стойкости шифра
Cipher strength Score 0 bits (no encryption) 0% < 128 bits (e.g., 40,56) 20% < 256 bits (e.g., 128, 168) 80% >= 256 bits (e.g., 256) 100%
Оглядываясь назад на более подробные результаты, включенные в вопрос, мы видим, что в конфигурации только для TLS1.2 вы использовали только 256-битные шифры (хотя некоторые наборы шифров не одобрялись), в то время как в TLS1. 2 + TLS1.3, вы использовали сочетание 128-битных и 256-битных шифров.
Основываясь на их рейтинговой системе, это объясняет, почему вы получили пониженный балл в «Cipher Strength».
Теперь это в значительной степени подчеркивает, что, хотя этот инструмент является очень полезным ресурсом (особенно для выявления фактических плохих конфигураций), не стоит уделять слишком много внимания точному подсчету, а не смотреть на весь отчет.
Что касается того, что на самом деле является разумной настройкой TLS, если у вас нет четкого представления о том, что вам нужно, я бы посоветовал взглянуть на Серверный TLS руководство, поддерживаемое командами Mozilla по операционной безопасности и корпоративной информационной безопасности.
В частности, их «промежуточная» конфигурация обеспечивает хороший баланс между широкой совместимостью и безопасностью, а также имеется генератор конфигурации для популярных серверов TLS для удобного преобразования предлагаемых настроек в фактическую конфигурацию сервера.
Это возможно за счет соответствия TLS1.3 путем настройки OpenSSL для исключения некоторых шифров для использования TLS 1.3.
Я написал здесь краткое руководство:
TLS ВСЕ Вещи! подробное описание того, как этого добиться, а также включение минимального использования 112-битного эквивалента для остальной части ОС.
Здесь вы можете увидеть результат выполнения примера Вот
Обратите внимание на использование шифров CBC, обычно вы также хотите удалить их и запускать только GCM. Однако из-за большого количества посетителей вы можете пойти на этот риск вместо того, чтобы заставлять всех бегать вечнозеленые. (Будь вечнозеленым!)
В любом случае, часть, которая вас действительно интересует, это:
Набор шифров = TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256
Параметры = ServerPreference, PrioritizeChaCha
Добавив их в свою конфигурацию OpenSSL, вы эффективно удалите 128-битные параметры ... Nginx по-прежнему будет выполнять конфигурацию TLS 1.2 и т.д. для вас, поскольку этот двоичный файл управляет этими настройками вместо OpenSSL. Остальная часть вашей ОС, зависящая от настроек в OpenSSL, впоследствии также будет их использовать! (настоятельно рекомендуется)