- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день.
Задумался об оптимизации ssl в nginx.
Сейчас пока использую только это
Думаю добавить еще такое.
А вот с ssl_ciphers не пойму какие лучше указать, сейчас по умолчанию используются.
Не пойму по ssl_session_ticket_key, мне самому на сервере с генерировать ключи эти?
А так же ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
Как я понимаю протоколы эти сильно устарели и больше ни кем не поддерживаются TLSv1 TLSv1.1 , можно их поддержку на сервер убрать.
уже не первый год включены лишь 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 установлен в системе?
даже если не установлен. можно отдельно собрать openssl 1.1 и собрать nginx, использующий именно этот openssl, а не системный.
хотя и в том что используется какая-то свежая ОС уже с openssl 1.1 тоже ничего необычного.
даже если не установлен. можно отдельно собрать openssl 1.1 и собрать nginx, использующий именно этот openssl, а не системный.
хотя и в том что используется какая-то свежая ОС уже с openssl 1.1 тоже ничего необычного.
Конечно можно всё, опять возвращаемся к вопросу: Чего мы хотим добиться?
Если делать нехрена и это последнее, чем можно заняться, то конечно без проблем. Только не надо это оптимизацией называть.
цель указана - оптимизация.
оптимизация это обычно означает какое-то улучшение или ускорение через убирание лишнего хлама.
но начинать надо с матчасти. понимать самостоятельно суть каждой настройки, а не просто копипастить что-то с форумов :)
по пунктам:
1) HSTS - да, но надо помнить о переходе обратном с https->http
да т.к. браузер в следующие заходы будет сразу обращаться куда надо, без лишнего обращения к http->редирект->https
2) tls 1.2 и 1.3 остальное отключено - да, но тоже надо помнить о древних клиентах.
3) ssl_stapling - да, но надо помнить о нюансе с dns и возможных тормозах из-за этого.
1 А зачем обратно переводить домен с https на http, еще такого не возникала.
2 Я понимаю что есть какае-та часть клиентов на древнем софте и на древнем железе.
3 Понял.
Пока что разбираюсь с параметром ssl_ciphers, остальное понятно.
А белые боты, яндекса и гугла перешли с tls 1.1 на tls 1.2?
насчёт У вас Openssl 1.1 установлен в системе?
Да!