Комментарии 92
Каждый год одно и то же :) Однако спасибо за информацию по производительности.
Вместо тысячи слов: https://mozilla.github.io/server-side-tls/ssl-config-generator/
И https://wiki.mozilla.org/Security/Server_Side_TLS где описаны ciphersuites для поддержки разных наборов браузеров.
Вы сами-то пробовали делать всё по рекомендациям там? В типа "совместимом" варианте там сразу после разных вариантов ECDHE идёт DHE-RSA-AES128. С этим шифром вы либо потеряете Java 6u45, либо получите оценку B по тесту. Не совместимость, а смех какой-то.
Я базируюсь на их intermediate профиле, а не compatible. Но не суть.
Про совместимость с jre есть отдельные приколы, которые всё равно требуют вмешательства со стороны клиентов на java. Например, если удаленный сервер использует dh_params на 4 килобита (а таких после прошлых публичных воплей про слабые dh_params стало много), надо явно исключать часть алгоритмов в коде.
Ну вот, пойдите и доказывайте Яндекс.Деньгам что им нужно в коде что-то там убрать чтобы вы смогли принимать платежи на вашем сайте. Как думаете, сможете убедить?
Интеграция с легаси — отдельное развлечение. Они, извините, SNI не поддерживают, и это в 2017 году.
Вменять в вину отсутствие поддержки SNI можно браузеру, а для сервера это только плюс.
Когда в современном мире сервер не поддерживает SNI — это как минимум странно. Большинство его поддерживает не менее 5 (sic!) лет, некоторые уже более 10. Какой вы видите плюс в отсутствии поддержки SNI сервером?
«Доступ по HTTPS от Cloudflare или Let's Encrypt работает по технологии SNI». С Cloudflare понятно, но про Let's Encrypt-то — как сертификат завязан на технологию сервера?
Никак, просто бумажку писали идиоты. На сервере, использующем сертификат от LE (или любого другого CA) может быть как один (т. е. эффективно без SNI, вне зависимости от поддержки со стороны сервера), так и несколько хостов, имеющих различные сертификаты.
Часть, в которой LE и CF похоже — использование SAN (subjectAltName), но большинство CA его тоже используют (например, в CN
— exmaple.com
, а в SAN
— www.example.com
, так что наиболее вероятным остаются первое предположение.
Прочитайте здесь: https://habrahabr.ru/post/325230/#nedostatki
Если вы делаете как по ссылке, то вы сами себе создаёте заботу. Вся статья о том чтобы не делать так, как делается в том генераторе.
ssl_protocols TLSv1.2;
Как ни крути, есть динозавры, которые по TLSv1.2 просто не работают, в итоге нужно указывать 1/1.1/1.2. Если цель была показать цену 100% результата, то вы таки добились этого (мне статья понравилась, в частности того, что я пропустил как-то мимо ушей
ssl_ecdh_curve
и у вас хорошо расписаны шифры).И немного вопросов:
- Чем вызван отказ от:
ssl_prefer_server_ciphers on;
? - Почему ssl настроен без http2 (конфиг nginx) и ALPN (с openssl 1.0.2+)?
- У вас не используется
ssl_dhparam
, по логике ECDHE вылезают из DHE, и должны использовать этот файл.
Во второй части статьи для динозавров мы возвращаем старые протоколы и так далее для максимальной совместимости. Посмотрите ещё раз, пожалуйста.
По вопросам:
ssl_prefer_server_ciphers on
в Debian прописано по умолчанию.- потому что даже в Debian testing nginx собран с OpenSSL 1.0.1t без ALPN
ssl_dhparam
не используется потому что не используются шифры DHE
На тему http2+ALPN — можно скачать исходники nginx и собрать «правильный».
ssl_prefer_server_ciphers по дефолту off;, но я никогда не видел конфига nginx из пакетов, так как никогда его из пакетов не ставил, тут спорит не буду.
Хотя у вас в статье не указано, что последний из пакетов.
# nginx -V
nginx version: nginx/1.10.3
built with OpenSSL 1.1.0d 26 Jan 2017 (running with OpenSSL 1.1.0e 16 Feb 2017)
Из них исключим шифры слабее 256 бит
Этому будет какое-то обоснование? Так вы поднимаете требования к памяти и CPU клиентов, но далеко не факт, что как-то улучшаете ситуацию.
И, возможно, будет полезен guard вида !EXPORT
, чтобы нечаянно не напороться, разрешив что-нибудь лишнее, что включает "экспортные" версии шифров
По-хорошему надо ещё выпилить SSLv3 полностью из протоколов. В последнем конфиге этого не указано, если я правильно его прочел. IE8/XP все равно сумеют связаться с сервером с использованием TLS1.0.
PS: так и хочется просто скопипастить Ваш конфиг в «Итого», однако попробую пройти по всему пути сам.
Спасибо, будем пробовать.
nginx-1.6.2.tar.gz 16-Sep-2014
серьезно?
Более новая версия ровным счётом ничего не меняет: даже в backports она собрана с не самой свежей OpenSSL.
Можно пересобрать с самой свежей — спору нет. Но тогда прощай DES-CBC3-SHA
и IE8/XP. Если вам это не важно, то вперёд.
Если вам не важно наличие 3-х security vulnerabilities в указанной вами версии, то удачи.
Очень интересно, жду пруфлинки. Версия 1.6.2-5+deb8u4.
Все доступно на оф. сайте
A problem was identified in nginx code responsible for saving
client request body to a temporary file. A specially crafted request
might result in worker process crash due to a NULL pointer dereference
while writing client request body to a temporary file (CVE-2016-4450).
The problem affects nginx 1.3.9 — 1.11.0.
The problem is fixed in nginx 1.11.1, 1.10.1.
Patch for nginx 1.9.13 — 1.11.0 can be found here:
http://nginx.org/download/patch.2016.write.txt
Patch for older nginx versions (1.3.9 — 1.9.12):
Several problems in nginx resolver were identified, which might
allow an attacker to cause worker process crash, or might have
potential other impact:
Invalid pointer dereference might occur during DNS server response
processing, allowing an attacker who is able to forge UDP
packets from the DNS server to cause worker process crash
(CVE-2016-0742).
Use-after-free condition might occur during CNAME response
processing. This problem allows an attacker who is able to trigger
name resolution to cause worker process crash, or might
have potential other impact (CVE-2016-0746).
- CNAME resolution was insufficiently limited, allowing an attacker who
is able to trigger arbitrary name resolution to cause excessive resource
consumption in worker processes (CVE-2016-0747).
The problems affect nginx 0.6.18 — 1.9.9 if the "resolver" directive
is used in a configuration file.
The problems are fixed in nginx 1.9.10, 1.8.1.
Several problems in nginx resolver were identified, which might
allow an attacker to cause worker process crash, or might have
potential other impact:
Invalid pointer dereference might occur during DNS server response
processing, allowing an attacker who is able to forge UDP
packets from the DNS server to cause worker process crash
(CVE-2016-0742).
Use-after-free condition might occur during CNAME response
processing. This problem allows an attacker who is able to trigger
name resolution to cause worker process crash, or might
have potential other impact (CVE-2016-0746).
- CNAME resolution was insufficiently limited, allowing an attacker who
is able to trigger arbitrary name resolution to cause excessive resource
consumption in worker processes (CVE-2016-0747).
The problems affect nginx 0.6.18 — 1.9.9 if the "resolver" directive
is used in a configuration file.
The problems are fixed in nginx 1.9.10, 1.8.1.
Several problems in nginx resolver were identified, which might
allow an attacker to cause worker process crash, or might have
potential other impact:
Invalid pointer dereference might occur during DNS server response
processing, allowing an attacker who is able to forge UDP
packets from the DNS server to cause worker process crash
(CVE-2016-0742).
Use-after-free condition might occur during CNAME response
processing. This problem allows an attacker who is able to trigger
name resolution to cause worker process crash, or might
have potential other impact (CVE-2016-0746).
- CNAME resolution was insufficiently limited, allowing an attacker who
is able to trigger arbitrary name resolution to cause excessive resource
consumption in worker processes (CVE-2016-0747).
The problems affect nginx 0.6.18 — 1.9.9 if the "resolver" directive
is used in a configuration file.
The problems are fixed in nginx 1.9.10, 1.8.1.
Может я открою страшную тайну, но есть официальный репозиторий:
For Debian replace codename with Debian distribution codename, and append the following to the end of the /etc/apt/sources.list file:
deb http://nginx.org/packages/debian/ codename nginx
deb-src http://nginx.org/packages/debian/ codename nginx
а в указанной автором версии есть на данный момент 3 security vulnerabilities
Как интересно, а есть опыт настройки SSL под http/2? Мне никак не удается настроить forward secrecy c http/2, поэтому мой предел — A-
.
Вот ssl.conf который у меня инклюдится в файлы всех доменов.
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_dhparam /etc/nginx/dhparam.2048.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_session_tickets off;
resolver 8.8.8.8;
add_header Strict-Transport-Security "max-age=31536000";
Ну и
server {
listen bla-bla.tld:443 http2;
}
в конфиге самого домена
https://www.ssllabs.com/ssltest/analyze.html?d=gorky.media
Forward Secrecy Yes (with most browsers) ROBUST (more info)
ALPN Yes
NPN Yes h2 http/1.1
Настройки оптимальны, ибо даже из под XP с последними для него Хромом и Файрфоксом все работает. Если еще чуть-чуть попробовать закрутить, то ломается XP, а у меня у одного из клиентов много посетителей из под XP, пришлось из-за них гайки слегка развинчивать.
A+, все прекрасно, но XP на сайты попадают.
Старую версию Java потеряли, медленные DHE шифры не исключили. Статью не читали, да?
ssl on;
как пишут нам на сайте nginx.org:
It is recommended to use the ssl parameter of the listen directive instead of this directive.
Под nginx/1.11.10 без ALPN всё настраивается с http/2 как в посте написано. Результат тоже. Проверял здесь.
Теперь в SSL Labs только один пункт остался для меня неразрешенным: DNS CAA.
Подскажите, у кого из DNS-провайдеров сервер поддерживает добавление записей CAA? У Яндекса в подключенном к Яндекс.ППП DNS-сервере я такого не отыскал. Что я делаю не так?)
Пока не слишком широкая поддержка этого вида записей.
Public Key Pinning разгадали? Там ничего сложного, но уже точно сделать можно в отличии от CAA.
DNS CAA определяет кто может выдавать сертификаты для домена. DANE совсем про другое.
Это наступит не раньше тотального внедрения DNSSEC, а это не похоже что наступит скоро...
А за вами, DNSSEC, зайдут после IPv6
Вы считаете лучше не иметь вообще никаких ограничений по выдаче сертификатов, чем иметь какие-то, хоть не совсем надежные?
Мне кажется вы не понимаете разницы между DNS CAA и DANE. Рад буду ошибаться.
Вы считаете лучше не иметь вообще никаких ограничений по выдаче сертификатов, чем иметь какие-то, хоть не совсем надежные?
В данном случае да. Потому что DNS уже массово подменяется. Без DNSSEC это не защита, а дополнительная точка для атаки. Кроме того, нет ничего хуже, чём ложное чувство защищённости, когда её нет. Уж лучше пусть все знают что сейчас проблема с СА есть и её надо решать, чем думают что всё ок и левый сертификат для их домена никто не сможет выпустить.
Мне кажется вы не понимаете разницы между DNS CAA и DANE. Рад буду ошибаться.
Очень может быть. Насколько я понимаю DANE нужна для того, чтобы домен мог БЕЗОПАСНО и НАДЁЖНО сообщить информацию о своём сертификате (в общем случае, можно CA, можно сертификат, можно их хеши). Это позволяет защититься от выпуска левых сертификатов. Причём решение очень гибкое. Подходит и для самоподписных сертификатов.
А что такое DNS CAA, это только ограничение на СА и всё. Возможностей меньше. Без DNSSEC верить обоим типам записей нельзя (если на это реально плевать, так можно и записи DANE передавать без DNSSEC, технически то можно...).
Вот мне и не ясно, зачем нужен ущербный вариант с CAA, если есть уже хороший DANE?
То есть вы считаете что лучше вообще не пользоваться CAA? Вы считаете что от такой записи рядом с вашим доменом ровным счетом никакой пользы?
DANE призван полностью устранить СА из уравнения. То есть, получать сертификаты без них. Совершенно новая схема.
CAA призван ограничить полномочия CA. То есть, все то же, что обычно, но с ограничениями.
Если кто-то собирается эту процедуру проходить — закладывайте время
Пруф: https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Спасибо за ссылку. Всё даже хуже. Так как в nginx по-умолчанию используются шифры из группы HIGH, то вполне возможно уже с версии OpenSSL 1.0.2 шифров 3DES не будет в списке шифров по умолчанию, а значит уже тогда пользователи IE8 останутся без половины интернета.
IE8 уже даже в статистике не видно, на уровне статистической погрешности.
Зачем тащить за собой дохлую корову?
Гораздо хуже: есть весьма обеспеченные люди, приносящие бизнесам существенный доход, которые не спешат выбрасывать старый компьютер. Вполне возможно они богатые в том числе потому что не гонятся за новинками. Очень сложно вот взять и отбросить таких клиентов. Конечно, это проблема — не проблема сайтов уровня персонального блога.
echo 'deb http://ftp.debian.org/debian jessie-backports main' > /etc/apt/sources.list.d/backports.list
apt-get update && apt-get -t jessie-backports install openssl nginx -y && systemctl enable nginx && systemctl start nginx
Получается на выходе nginx/1.9.10 built with OpenSSL 1.0.2j
ALPN есть, HTTP/2 есть, репозиторий официальный, сборка из исходников не нужна, всё хорошо.
nginx надо ставить из родных репозиториев.
For Debian replace codename with Debian distribution codename, and append the following to the end of the
/etc/apt/sources.list file:
deb http://nginx.org/packages/debian/ codename nginx
deb-src http://nginx.org/packages/debian/ codename nginx
For Ubuntu replace codename with Ubuntu distribution codename, and append the following to the end of the /etc/apt/sources.list file:
deb http://nginx.org/packages/ubuntu/ codename nginx
deb-src http://nginx.org/packages/ubuntu/ codename nginx
При этом лучше брать таки mainline, это — официальный совет из доков на самом nginx.org. А брать старый mainline из которого уже вышел stable — дурная идея.
В официальных nginx с какой версией OpenSSL собран, простите?
Что-то мне подсказывает что не с 1.0.2j, а более ранней. А значит никакого ALPN.
Статья писалась на Debian 8 (об этом в начале статьи прям чёрным по белому), в котором такие-то версии OpenSSL со своими патчами. В других дистрибутивах может быть всё что угодно. Именно потому в статье не просто даётся итоговый рецепт, а рассказывается как вы можете на своей версии OpenSSL получить оптимальный список шифров.
Если по делу, вам нужно посмотреть какие шифры даёт команда со итоговым списком:
openssl ciphers -v 'EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4' | column -t
Может быть там есть какой-то небезопасный или устаревший шифр, который так полюбился IE 11 / Win Phone 8.1. Если такой есть, исключите группу с ним и попробуйте ещё раз с новым набором шифров.
Дело ещё может быть в том, что у вас в nginx.conf
нет директивы, обязывающей клиентов выбирать шифры из вашего списка согласно вашего порядка. Добавьте её если её нет:
ssl_prefer_server_ciphers on;
что у вас в nginx.conf нет директивы
И правда, хотя ставил версию из официального репозитория nginx. Ещё пришлось добавить !MD5, чтобы выключить 3DES-MD5.
Может быть внесёте дополнение в финальный конфиг?
OpenSSL, ssl_ciphers и nginx: прокачиваем на 100%