nginx ssl оптимизация

уже не первый год включены лишь tls 1.2 и 1.3, остальное выключено.

крайне изредка кто-то под какой-нибудь winxp или ie древним замечает мол не открывается сайт и жалуется.

объясняю что да как. соглашаются что так пусть и остается.

пример сайта:

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

ни одного "желтого", лишь кое-что красное из-за тех самых отключенных более старых протоколов.

все "зеленые полоски" можно довести до максимума, увеличив размеры ключей с 2048 до 4096

но это немного отразится на производительности. пока не помечает ssllabs желтым, пусть остается так.

Strict-Transport-Security тоже включен, но надо осознавать потенциальную проблему перехода обратно с https на http.

если к примеру вздумается и по http домен открыть, на который браузер уже заходил с таким заголовком, то ничего не получится. браузер будет упорно ломиться только на https сразу пока не наступит таймаут указанный в max-age

сбросить это можно, но не так просто как куки например.

по шифрам. у меня так:

ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE:+AES256:+CHACHA20:!AESCCM:!SHA384:!SHA256:!SHA:-3DES:!NULL:!RC4:!ARIA:!CAMELLIA';
т.е. сообщаем о приоритете шифров сервера, а не клиента.

потом AES256 - как среднее между менее быстрым AES384 и более быстрым, но менее безопасным (или ssllabs его желтым отмечает, уж не помню) AES128.

CHACHA20  - для клиентов, чьи процессоры не имеют аппаратного AES.

остальное отключено (! знак)

помимо этого, nginx использует openssl, в которой тоже можно настроить шифры, протоколы и т.д.

у меня допустим так сделано:

в файле openssl.cnf добавлено:

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
CipherString = ECDHE:+AES256:+CHACHA20:!AESCCM:!SHA384:!SHA256:!SHA:-3DES:!NULL:!RC4:!ARIA:!CAMELLIA
Options = ServerPreference,PrioritizeChaCha

т.е.  тоже самое, протоколы только tls 1.2 и 1.3

те же шифры AES256 и CHACHA20, но еще доступен также AES128 (уж не вспомню так с ходу почему и зачем)

PrioritizeChaCha  - там как-то хитро помнится... клиенты, которые могут AES, все равно будут AES256 использовать. а это лишь для тех кто не может.

это тоже включено у меня:

ssl_stapling on;
ssl_stapling_verify on;
но!  не так давно из-за этого возникала одна проблема, которую не так просто было обнаружить.

суть вроде в том была, что при этом еще происходит обращение к dns серверам (из /etc/resolv.conf или там же в nginx конфиге resolver и resolver_timeout)

так вот однажды заметил что https сайты как-то тормознуто отвечают. начал ковырять, при перезагрузке nginx вообще страшно медленно это делал.

оказалось что по какой-то причине временно была плохая связь с гугловскими днс (8.8.8.8) или они сами по себе подтормаживали.

и при перезапуске nginx с парой сотен доменов с сертификатами и ssl_stapling'ом, происходило множество обращений к dns и отсюда тормоза.

в итоге решил дополнительной установкой локального кэширующего dnsmasq и указанием его как единственного в системе.

после чего nginx стал перегружаться моментом и все тормоза пропали.

вот такая история, о которой надо помнить, используя ssl_stapling

вот такие последовательности.

tls1.3 как nginx конфиге - AES256, потом CHACHA20

tls1.2 - как в openssl - AES128, AES256, CHACHA20

даже не спрашивайте почему так :)

довольно давно это настраивал. там все достаточно сложно замудрено.

но суть в том что надо во-первых требовать приоритета сервера и сервер чтоб в первым делом хотел один из AES'ов, лучше 128 т.к. он быстрей, а следующим CHACHA20 для недоклиентов.

весь остальной хлам просто отключаем.

Я думаю в любых изменениях должна быть цель.

Какую цель хочет добиться, ТС. Надо с этого начинать.

цель указана - оптимизация.

оптимизация это обычно означает какое-то улучшение или ускорение через убирание лишнего хлама.

но начинать надо с матчасти. понимать самостоятельно суть каждой настройки, а не просто копипастить что-то с форумов :)

по пунктам:

1) HSTS - да, но надо помнить о переходе обратном с https->http

да т.к. браузер в следующие заходы будет сразу обращаться куда надо, без лишнего обращения к http->редирект->https

2) tls 1.2 и 1.3 остальное отключено - да, но тоже надо помнить о древних клиентах.

3) ssl_stapling - да, но надо помнить о нюансе с dns и возможных тормозах из-за этого.

Оптимизация это ПРОЦЕСС, с помощью которого достигается некая цель. Не нужно путать слова.

С ваших слов, это больше похоже на: "Мне нехер делать, давайте nginx конфиг покручу."

даже если не установлен. можно отдельно собрать openssl 1.1 и собрать nginx, использующий именно этот openssl, а не системный.

хотя и в том что используется какая-то свежая ОС уже с openssl 1.1 тоже ничего необычного.

Конечно можно всё, опять возвращаемся к вопросу: Чего мы хотим добиться?

Если делать нехрена и это последнее, чем можно заняться, то конечно без проблем. Только не надо это оптимизацией называть.

1 А зачем обратно переводить домен с https на http, еще такого не возникала.

2 Я понимаю что есть какае-та часть клиентов на древнем софте и на древнем железе.

3 Понял.

Пока что разбираюсь с параметром ssl_ciphers, остальное понятно.

А белые боты, яндекса и гугла перешли с  tls 1.1 на  tls 1.2?

Да!