Comments 92

Вы сами-то пробовали делать всё по рекомендациям там? В типа "совместимом" варианте там сразу после разных вариантов ECDHE идёт DHE-RSA-AES128. С этим шифром вы либо потеряете Java 6u45, либо получите оценку B по тесту. Не совместимость, а смех какой-то.

Я базируюсь на их intermediate профиле, а не compatible. Но не суть.


Про совместимость с jre есть отдельные приколы, которые всё равно требуют вмешательства со стороны клиентов на java. Например, если удаленный сервер использует dh_params на 4 килобита (а таких после прошлых публичных воплей про слабые dh_params стало много), надо явно исключать часть алгоритмов в коде.

Интеграция с легаси — отдельное развлечение. Они, извините, SNI не поддерживают, и это в 2017 году.

Вменять в вину отсутствие поддержки SNI можно браузеру, а для сервера это только плюс.
Упс, ссылку не читал, моя вина. Тут ЯД как раз «браузер». Но странность там всё-таки есть: «Доступ по HTTPS от Cloudflare или Let's Encrypt работает по технологии SNI». С Cloudflare понятно, но про Let's Encrypt-то — как сертификат завязан на технологию сервера?
Вменять в вину отсутствие поддержки SNI можно браузеру, а для сервера это только плюс.

Когда в современном мире сервер не поддерживает SNI — это как минимум странно. Большинство его поддерживает не менее 5 (sic!) лет, некоторые уже более 10. Какой вы видите плюс в отсутствии поддержки SNI сервером?


«Доступ по HTTPS от Cloudflare или Let's Encrypt работает по технологии SNI». С Cloudflare понятно, но про Let's Encrypt-то — как сертификат завязан на технологию сервера?

Никак, просто бумажку писали идиоты. На сервере, использующем сертификат от LE (или любого другого CA) может быть как один (т. е. эффективно без SNI, вне зависимости от поддержки со стороны сервера), так и несколько хостов, имеющих различные сертификаты.
Часть, в которой LE и CF похоже — использование SAN (subjectAltName), но большинство CA его тоже используют (например, в CNexmaple.com, а в SANwww.example.com, так что наиболее вероятным остаются первое предположение.

Я имел в виду плюс для клиента, а не для самого сервера. Клиенту ведь безразлично, поддерживает сервер SNI или нет (при условии, что у него всё, что нужно, открывается). А плюс для него один — поддержка XPIE8 (специфический плюс, но кому-то важно).
Это, конечно, круто, но…
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
Это хорошо, что ECDHE не требует dh_param, буду знать.

На тему http2+ALPN — можно скачать исходники nginx и собрать «правильный».
ssl_prefer_server_ciphers по дефолту off;, но я никогда не видел конфига nginx из пакетов, так как никогда его из пакетов не ставил, тут спорит не буду.
Хотя у вас в статье не указано, что последний из пакетов.
Debian Stretch скоро пойдёт в релиз:
# 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 клиентов, но далеко не факт, что как-то улучшаете ситуацию.

Обноснование — получить 100% оценку по тесту. Дальше про CPU написано и расписано, почитайте.

Да уже прочитал, извиняюсь. Начало статьи дало неправильные ожидания. Так статья вполне годная.

И, возможно, будет полезен guard вида !EXPORT, чтобы нечаянно не напороться, разрешив что-нибудь лишнее, что включает "экспортные" версии шифров

OpenSSL 1.0.1t ничего про экспортные версии шифров не знает. Нет смысла исключать то, чего нет.


$ openssl ciphers EXPORT
Error in cipher list

Вашей инструкцией может воспользоваться кто-нибудь с 0.9.9 или не отключенными при сборке экспортными шифрами.

Тест не даст хороших оценок с экспортными шифрами. Чай разберутся как-нибудь, раз уж разобрались как OpenSSL собирать без отключенных экспортных шифров.

По-хорошему надо ещё выпилить SSLv3 полностью из протоколов. В последнем конфиге этого не указано, если я правильно его прочел. IE8/XP все равно сумеют связаться с сервером с использованием TLS1.0.

В Debian по-умолчанию SSLv3 выключен. Иначе б не видать хороших оценок.

Огромное спасибо за подробное объяснение параметров и ключей.
PS: так и хочется просто скопипастить Ваш конфиг в «Итого», однако попробую пройти по всему пути сам.
В свое время убил несколько часов на подгон ssl_ciphers под A+ в данном тесте.
Спасибо, будем пробовать.
Мозилловский ssl_ciphers с HSTS даёт A+, тут интересна конфигурация с тагами и приоретизация.
UFO landed and left these words here
«Это же» не мешает скачать с оффициального сайта исходники и самому собрать.
Лёгким движением ./configure && make && make install любой дистрибутив превращается слакварь

Более новая версия ровным счётом ничего не меняет: даже в backports она собрана с не самой свежей OpenSSL.


Можно пересобрать с самой свежей — спору нет. Но тогда прощай DES-CBC3-SHA и IE8/XP. Если вам это не важно, то вперёд.

Если вам не важно наличие 3-х security vulnerabilities в указанной вами версии, то удачи.

Все доступно на оф. сайте


CVE-2016-4450 - имеется патч

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):


http://nginx.org/download/patch.2016.write2.txt


CVE-2016-0742

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.


CVE-2016-0746

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.


CVE-2016-0747

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.

Вы правы, данные SV были пропатчены.
Тем не менее, я все равно не вижу патчей из списка отсюда


Не говоря уже о доступности нового функционала, отсутствие поддержки HTTP2 (в 1.6.2 присутствует SPDY), отсутствие динамических модулей и остальных нововведений.

Может я открою страшную тайну, но есть официальный репозиторий:


Debian reposirtory
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 шифры не исключили. Статью не читали, да?

Статья вредна. Загонять все в 100 будет только дрочер которому нечего делать. А это — пример реального конфига с боевого сервера.

Вы не поверите, но статья именно что о том почему загонять всё в 100% не стоит. С бенчмарками и прочим. Это, конечно, если дальше заголовка прочитать.

ssl on;

как пишут нам на сайте nginx.org:


It is recommended to use the ssl parameter of the listen directive instead of this directive.
Спасибо, файл достаточно старый и просто дополнялся и менялся, а ssl on; как висел, так и висит. Надо посмотреть, скорее всего http2 в listen решает это дело сейчас, тогда просто уберу.
Спасибо за подробное объяснение!
Теперь в SSL Labs только один пункт остался для меня неразрешенным: DNS CAA.
Подскажите, у кого из DNS-провайдеров сервер поддерживает добавление записей CAA? У Яндекса в подключенном к Яндекс.ППП DNS-сервере я такого не отыскал. Что я делаю не так?)

Пока не слишком широкая поддержка этого вида записей.


Public Key Pinning разгадали? Там ничего сложного, но уже точно сделать можно в отличии от CAA.

Я что-то совсем запутался. Зачем нужен DNS CAA, если уже вроде есть DNS TLSA (DANE)?

DNS CAA определяет кто может выдавать сертификаты для домена. DANE совсем про другое.

А про что тогда DANE? Насколько я понял, DANE может указывать или на конкретный сертификат (или его хеш) или на сертификат CA, который обслуживает данный домен (если говорить точнее, то там можно отдельные значения для разных портов и даже протоколов делать). Я в чём-то не прав?
Я жду, когда все таки начнут использовать DANE. Это будет началом конца всех центров центров выдачи сертификатов.

Это наступит не раньше тотального внедрения DNSSEC, а это не похоже что наступит скоро...

Дык любая информация из DNS о сектификатах и тому подобном без DNSSEC бессмысленна, т.к. не достоверна. Какой смысл в записи о том, что нужно использовать только CA «abc», если эту запись можно подделать?

Вы считаете лучше не иметь вообще никаких ограничений по выдаче сертификатов, чем иметь какие-то, хоть не совсем надежные?


Мне кажется вы не понимаете разницы между DNS CAA и DANE. Рад буду ошибаться.

Вы считаете лучше не иметь вообще никаких ограничений по выдаче сертификатов, чем иметь какие-то, хоть не совсем надежные?

В данном случае да. Потому что DNS уже массово подменяется. Без DNSSEC это не защита, а дополнительная точка для атаки. Кроме того, нет ничего хуже, чём ложное чувство защищённости, когда её нет. Уж лучше пусть все знают что сейчас проблема с СА есть и её надо решать, чем думают что всё ок и левый сертификат для их домена никто не сможет выпустить.

Мне кажется вы не понимаете разницы между DNS CAA и DANE. Рад буду ошибаться.

Очень может быть. Насколько я понимаю DANE нужна для того, чтобы домен мог БЕЗОПАСНО и НАДЁЖНО сообщить информацию о своём сертификате (в общем случае, можно CA, можно сертификат, можно их хеши). Это позволяет защититься от выпуска левых сертификатов. Причём решение очень гибкое. Подходит и для самоподписных сертификатов.

А что такое DNS CAA, это только ограничение на СА и всё. Возможностей меньше. Без DNSSEC верить обоим типам записей нельзя (если на это реально плевать, так можно и записи DANE передавать без DNSSEC, технически то можно...).

Вот мне и не ясно, зачем нужен ущербный вариант с CAA, если есть уже хороший DANE?

То есть вы считаете что лучше вообще не пользоваться CAA? Вы считаете что от такой записи рядом с вашим доменом ровным счетом никакой пользы?

Не совсем. Мне не понятно зачем нужна ещё одна запись, если есть записи типа DANE. Их тоже можно передавать без DNSSEC`а. И будет тоже самое, даже более гибко (я считаю что то что будет — будет фигнёй, но это уже моё личное мнение). Или я ошибаюсь?

DANE призван полностью устранить СА из уравнения. То есть, получать сертификаты без них. Совершенно новая схема.


CAA призван ограничить полномочия CA. То есть, все то же, что обычно, но с ограничениями.

DANE призван полностью устранить СА из уравнения.

Разве? Ведь DANE поддерживает и указание CA для домена, а не только сертификата. Просто если то что вы сказали действительно верно, то я снимаю все свои вопросы.
Кстати по-поводу получения сертификатов, мы тут недавно получали сертификат EV у Комодо и это просто превратилось таки в длительный квест. Нужные сертификаты получились с третьего раза — мы заказывали на три домена, заняло все это мероприятие почти два месяца.
Если кто-то собирается эту процедуру проходить — закладывайте время
Важная информация для тех, кому критична поддержка XP+IE8: начиная с версии OpenSSL 1.1.0 по умолчанию выпилен triple-DES. И, например, в грядущем Debian Stretch nginx собран уже именно с 1.1.0. Это означает, что сайт у посетителей с XP+IE8 открываться не будет независимо от конфига nginx.
Пруф: https://www.openssl.org/blog/blog/2016/08/24/sweet32/

Спасибо за ссылку. Всё даже хуже. Так как в nginx по-умолчанию используются шифры из группы HIGH, то вполне возможно уже с версии OpenSSL 1.0.2 шифров 3DES не будет в списке шифров по умолчанию, а значит уже тогда пользователи IE8 останутся без половины интернета.

В общем случае вы правы, и все это понимают. Но, как мне кажется, могут существовать сайты, целевая аудитория которых не стремится быть на пике технологического прогресса (одинокие престарелые люди, детские дома, тяжёлые инвалиды, бюджетные учреждения и т. д.). Работает старенький компьютер — и ладно, а перестанет — и без него обойдёмся. Может быть, я лишнего выдумываю…

Гораздо хуже: есть весьма обеспеченные люди, приносящие бизнесам существенный доход, которые не спешат выбрасывать старый компьютер. Вполне возможно они богатые в том числе потому что не гонятся за новинками. Очень сложно вот взять и отбросить таких клиентов. Конечно, это проблема — не проблема сайтов уровня персонального блога.

Честно говоря, я вообще nginx беру с Dotdeb, а не из официальных или дебиановских репозиториев, поэтому не знаю.
Кстати, что до Debian. Я в Debian 8 ставлю nginx вот так:

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 есть, репозиторий официальный, сборка из исходников не нужна, всё хорошо.
1.9.10? Беда какая. mainline старый.
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.

На CentOS 7 тест стал выдавать A- из-за отсутствия FS для IE 11 / Win Phone 8.1.

Статья писалась на 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.

Может быть внесёте дополнение в финальный конфиг?

Этак нужно будет дополнить статью десятком конфигов для каждой из версий. Да и статья не про это. Если вы сами смогли разобраться что к чему и составить свой конфиг для своей версии сами, то значит статья свою задачу выполнила.

А вот ssl_trusted_certificate наоборот лишняя — сертификаты из неё не отправляются клиентам, но сам nginx берёт цепочку для OCSP из ssl_certificate.
Only those users with full accounts are able to leave comments. Log in, please.