Comments 55
Можно еще добавить HSTS-заголовок, тогда браузер запомнит, что сайт работает по https, и при следующих заходах не будет обращаться по http:

add_header Strict-Transport-Security max-age=31536000;
Так я же о нем уже написал изначально, только срок в моем примере неделя
либо это статьи «Делайте вот так», где просто даны настройки без каких-либо разъяснений и вариантов использования, либо это большие теоретические статьи
Хм?
Почему вы не вкомпиливаете SPDY в пакетах для debian wheezy? Там ведь openssl подходящей версии.
Почему вы так решили? =) Специально только что скачал пакет, проверил, spdy там есть.
Возможно неверно выразился — скажем по вашей ссылке нет описаний по настройке DHE/EECDH. А где есть — не всегда описаны другие парметры, т.е. нужно смотреть несколько статей (не всегда две) и сопоставлять информацию, если задаваться мыслью сделать не «чтобы было». Лучше наверное «Не нашел различных вариантов использования в одном месте», потому что даже наборы этих кодировок изначально для своего сервера я брал из комментариев к посту на Qualys, а не из самой статьи. Потом да, пост обновили и для этой статьи уже брались наборы из поста.
А у вас есть описание? =) По факту не нужно трогать, не будучи экспертом в вопросе. Недавно обсуждали про RC4:
Использование RC4 — это костыль, заметно ухудшающий безопасность с
остальных точек зрения. Его имело смысл использовать в момент
появления BEAST-атаки, сейчас — скорее не имеет.

Что до значения по умолчанию директивы ssl_ciphers, то оно выбрано
так, чтобы обеспечить максимальную безопасность на длинном отрезке
времени и требовать минимума изменений.

Что до ssl_prefer_server_ciphers, то оно имеет смысл в случае
использования конструкций вроде вышеописанного anti-BEAST решения.
Включать же его при ssl_ciphers по умолчанию — особого смысла нет.
mailman.nginx.org/pipermail/nginx-ru/2013-September/051978.html
кеши валидных сертификатов


не существует никаких кешей, существует только список отозванных сертификатов. Валидность проверяется по подписи сертификата проверенным центром сертификации. Если ругается несколько 1-2 дня, а потом не ругается значит дата выдачи из будущего…
Не знаком серьезно с ситемой проверки, однако странно то, что в первые дни некоторые бразуеры открывали страницу, а некоторые ругались. Например Opera и Firefox у меня ругались, а SRWare Iron (Chromium) — нет (на одной системе). При этом у знакомых мой сайт открывался в Firefox и Chrome нормально, а в опере тоже была ошибка. При этом у меня в Firefox стояли обе галочки в Настройки — Дополнительные — Сертфикаты — Настройки OCSP, а у знакомого вроде стандартно только одна стояла, сейчас точно не вспомню. Дата сертификата совпадала с временем получения. Что именно происходит при этом — не знаю.
Списками отозванных сертификатов уже никто не пользуется, а пользуются OCSP (Online Certificate Status Protocol). Не исключено, что startcom тяжело поддерживать инфраструктуру для бесплатных сертификатов, поэтому нормальные OCSP-ответы начинают приходить только через несколько дней.
Кстати, большинство браузеров для DV-сертификатов не пользуются OCSP.
Он манипулирует не только ими. OCSP-ответ для сертификата может быть revoked (если сертификат есть в CRL), unknown (видимо, то, что возвращает startcom) и good (для возврата которого недостаточно CRL, а нужен ещё список всех выданных сертификатов). Поэтому фраза «существует только список отозванных сертификатов» неверна.
Действительно, нашел старый скриншот, конкретно Firefox ругался «OCSP-сервер не имеет статуса этого сертификата. (Код ошибки: sec_error_ocsp_unknown_cert)».
Вот мы и поняли, почему сертификаты надо покупать, а не брать бесплатные :)
Скажу только, что в течении первых двух-трех дней браузеры, проверяющие сертификат на сервере, могут на него ругаться (у меня такое происходило с Opera 12 и Firefox), видимо у StartCom кеши валидных сертификатов обновляются не так часто.
Не очень понял о чём тут речь.
А вот выше уже ответили, не заметил.
Тогда другой вопрос — как именно ругались браузеры? Может просто промежуточного сертификата в цепочке не хватало?
Что-то вроде «Ошибка OCSP», сейчас уже точно не вспомню точно, промежуточный сертификат был. Ну и выше уже тоже прокомментировали подобное поведение.
Нашел старый скриншот… Конкретно Firefox ругался «OCSP-сервер не имеет статуса этого сертификата. (Код ошибки: sec_error_ocsp_unknown_cert)», так что вышенаписанное верно.
А как у вас на Qualys такие цифры? Можно ссылку на реальный сервер?

Лучшие цифры получить не удалось:

image
Это я понял, RC4 не отключить, иначе BEAST-уязвимость.

Но автор пишет:
Без SSLv3 такая настройка дает оценку 100-95-100-90
Ну и что, стремится любой ценой получить 100 попугаев, или же обеспечить поддержку браузеров, не понимающих TLS? Решать вам)
«Я стремлюсь» или «вы стремитесь получить… или обеспечить...»? Тогда стремиться, а то не совсем понятно к кому комментарий
ээм а можно вопрос?
есть сервер на котором несколько виртуальных хостов.
для одного их них требуется ssl и обычный хттп, для других этого не надо (оставляем только хттп)
вот для нужного делаю так.
/etc/nginx/sites-enabled/vhost_name.ru

server {
listen 80 default;
listen 443 ssl;       # порт https
server_name vhost_name.ru www.vhost_name.ru;

ssl_certificate     /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;

access_log /var/log/nginx/vhost_name.ru-access.log;
error_log  /var/log/nginx/vhost_name.ru-error.log  error;

client_max_body_size 300m;
......
......
}


всё круто начинает работать. НО если обратится к другому вхосту по https то откроется именно этот сайт vhost_name.ru
а вот не хотелось бы, хотелось бы чтоб на других ничегоне происходило, ну или запускался тотже сайт по хттпс, но не как не vhost_name.ru
nginx version: nginx/1.2.6
стандатрная поставка дебиана или dotdeb результаты равны
Увы, это невозможно в обычном случае. Можно сделать еще один сервер где идет default_server для 443 порта и return 444; однако тогда сайт будет открываться только в браузерах, поддерживающих SNI, т.к. если браузер не передает имя хоста в начале сессии, то nginx будет считать что запрошен дефолтный (где соединение закрывается), а не нужный вам сайт.
Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном общеизвестным центром сертификации, в то время как другие браузеры без проблем принимают этот же сертификат. Так происходит потому, что центр, выдавший сертификат, подписал его промежуточным сертификатом, которого нет в базе данных сертификатов общеизвестных доверенных центров сертификации, распространяемой вместе с браузером. В подобном случае центр сертификации предоставляет “связку” сертификатов, которую следует присоединить к сертификату сервера. Сертификат сервера следует разместить перед связкой сертификатов в скомбинированном файле:

$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt


nginx.org/ru/docs/http/configuring_https_servers.html
Это непринципиальная опечатка. Стоило просто написать автору в личку.
Непринципиальной она была бы если б не убивала добытый сертификат.
Во-первых, выстрелить в ногу в большинстве случаев вам не даст система:
-> % LANG=C cat f1 f2 >f1
cat: f1: input file is output file

Во-вторых, сертификат, как правило, можно загрузить повторно (у большинства CA и их партнеров).

В-третьих, reissue сертификата, как правило, не стоит денег.
Учитывая, что Вы поставили в теги только nginx, можно предположить, что и пользователи FreeBSD и будут попадаться на Вашу запись (т.к. nginx писался под него).
В FreeBSD cat f1 f2 > f1 очистит файл f1 и положит только f2.

Во-вторых и в-третьих уйдет время на дебаг (хоть и короткий) и эти самые «заново» и re-issue.
Вам не кажется, что полезно различать комментаторов и автора статьи?
Просто Вы так яростно защищали техническую неаккуратность данной статьи, что я не заметил, что автор другой.
Упс, переоптимизировал… Что-то мне казалось что все будет нормально, однако да…
[ts3@game ~/test]$ cat 1.txt
123
[ts3@game ~/test]$ cat 2.txt
456
[ts3@game ~/test]$ cat 1.txt 2.txt > 1.txt
[ts3@game ~/test]$ cat 1.txt
456

Исправил, спасибо
В CentOS/Fedora/RHEL нет поддержки ECC-алгоритмов в openssl, к сожалению. Можно использовать обычный kEDH.
можно самому собрать rpm-пакет nginx с последней версией openssl, тогда все будет.

приблизительный список изменений, которые для этого надо внести в spec
...
%define openssl_version 1.0.1e
...
Source0:    http://sysoev.ru/nginx/nginx-%{version}.tar.gz
...
Source4:    http://www.openssl.org/source/openssl-%{openssl_version}.tar.gz
...
%prep
%setup -q
%setup -q -b4
...
./configure \
...
    --with-openssl=../openssl-%{openssl_version} \
    --with-openssl-opt="no-threads no-shared no-zlib no-dso no-asm" \
...
#make %{?_smp_mflags}
make
...

Или пересобрать openssl, не накладывая патчи, удаляющие EC. В оригинальном spec'e вырезаются IDEA, RC-5, EC с помощью скрипта hobble-openssl.
если пересобрать пакет openssl-1.0.0 — это всеравно будет openssl-1.0.0,
без поддержки TLS v1.2 and TLS v1.1 и без поддержки AESGCM (only supported in TLS v1.2)

Ivan Ristic в своей статье
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

говорит, что "Today, only TLS 1.2 with GCM suites offer fully robust security." — так что с этой точки зрения лучше всего использовать latest версии openssl. тем более, что при использовании TLS 1.1+ и AES-CBC будет неуязвим атаке BEAST.
Я с вами полностью согласен.

К сожалению, далеко не все браузеры поддерживают TLSv1.1 и TLSv1.2.

И второй момент: не всем нужен такой уровень security. Для защиты формочки ввода пароля на личном bugzilla/redmine — он, как правило, не нужен.
Для включения Forward Secrecy можно использовать например такой набор шифров


какой именно набор шифров лучше всего использовать — зависит от очень многих причин.

основная статья на эту тему:
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

и вот один из вариантов выбора для современных версий openssl и процессоров с поддержкой AEN-NI:
mailman.nginx.org/pipermail/nginx-ru/2013-September/052007.html

кстати,
Updated SSL/TLS Deployment Best Practices Deprecate RC4
community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-deployment-best-practices-deprecate-rc4

в вашей статье зачем-то рекомендуется использовать RC4 — это противоречит статье Ivan Ristic
и новой (текущей) версии SSL/TLS Deployment Best Practices Version 1.3 от 17 September 2013:

«RC4 is weaker than previously thought. You should remove support for this cipher in the near future»
в вашей статье зачем-то рекомендуется использовать RC4


(уточнение) я говорю про фрагмент вашей статьи:

ssl_ciphers «RC4:HIGH:!aNULL:!MD5:!kEDH»;
Указывает используемые шифры. Собственно за счет изменения набора шифров и настраивается Forward Secrecy.

Не всем нужен идеальный уровень безопасности, а нагрузка возрастает. RC4 пока только слабее, но, оттуда же, «At the moment, the best attacks we know require millions of requests, a lot of bandwidth and time. Thus, the risk is still relatively low, but we expect that the attacks will improve in the future.».
Для тех, у кого цель поставить https для скажем phpmyadmin, личного svn/багтрекера или чего-то подобного для исключения перехвата при подключении через публичный WiFi или сеть предприятия этого более чем достаточно, тем более что часто их ставят на слабые системы вроде роутеров или NAS.
Возможно лучше поставить в первом примере набор с FS, а потом уже написать что для тех кто хочет сэкономить ресурсы можно поставить RC4…
… для тех кто хочет сэкономить ресурсы можно поставить RC4


1) не лучше. «AES-128 w/AESNI is 170% faster than RC4» — zombe.es/post/4078724716/openssl-cipher-selection
причем, практически все современные процессоры на серверах уже поддерживают набор инструкций AES-NI.

2) Ваша рекомендация ставить RC4 на первое место противоречит SSL/TLS Deployment Best Practices,
причем без каких-либо объяснений в тексте статьи, почему вы считаете, что Ivan Ristic не прав, а вы правы.

ssl_prefer_server_ciphers on;
ssl_ciphers «RC4:HIGH:!aNULL:!MD5:!kEDH»;


сайчас — не надо так делать. и не надо такие рекомендации давать всем «по умолчанию».
см. также habrahabr.ru/post/195808/#comment_6793484 — это мнение разработчиков nginx.
1) не лучше.
У них что-то не в порядке с производительностью RC4. И не указан размер блока, для которого строят графики и делают выводы.
Например, Xeon E3-1230
openssl speed rc4

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
rc4 531798.94k 722003.05k 832226.73k 868158.81k 880974.26k

openssl speed -evp aes-128-cbc

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 658585.29k 714082.85k 724060.07k 731471.03k 730118.16k

т.е. AES-NI быстрее только на 16-байтных блоках

В многопоточных тестах AES-128 будет быстрее на всех блоках, но незначительно, точно не 170%.

Ну и потом, почему Google, PayPal, Amazon, eBay, Apple (и многие другие известные конторы) используют RC4?
У них что-то не в порядке с производительностью RC4

это не у них. в старых версиях openssl было плохо с производительностью RC4, в более новых она выросла.

кстати, нашел в интернете еще вот такое сравнение производительности от Intel:
software.intel.com/sites/default/files/open-ssl-performance-paper.pdf
на странице 13 есть таблица 4 — во всех cлучаях aes-128-cbc быстрее rc4,
причем чуть ли не в два раза.

кроме того, есть еще один достаточно важный момент
openssl speed regarding AES-NI support
In TLS/SSL there is no encryption without message authentication. In
other words in the context you should also look at MAC performance, not
only cipher

— в статье от Intel это тоже сравнивается в таблице 5, и всегда AES в результате оказывается быстрее, чем RC4.

я эти данные еще раз перепроверил, aes-128-cbc-hmac-sha1 всегда быстрее, чем rc4-hmac-md5 при AES-NI
openssl 1.0.1e, опции сборки no-threads no-shared no-zlib no-dso no-asm no-krb5 linux-x86_64
процессор Xeon E3-1245 V2 @ 3.40GHz, load average: 0.10

$ ./openssl speed -evp rc4-hmac-md5
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4-hmac-md5    195896.23k   315770.94k   455434.67k   535356.07k   564751.02k

$ ./openssl speed -evp aes-128-cbc-hmac-sha1
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc-hmac-sha1   247201.31k   317473.58k   479607.64k   573098.33k   609331.37k


Ну и потом, почему Google, PayPal, Amazon, eBay, Apple (и многие другие известные конторы) используют RC4?

зашел на www.apple.com/ через Google Chrome: используется TLS 1.2, AES-256-CBC with SHA1 for message auth.

у paypal.com, например, cipher suites server-preferred order настроен по разному на разных IP: AES, RC4

то что много где еще используется RC4 — это наверное последствия многолетней борьбы с BEAST:

After the BEAST attack was disclosed in 2011, we—grudgingly—started using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and earlier. This caused the usage of RC4 to increase, and some say that it now accounts for about 50% of all TLS traffic.

рекомендация по возможности не использовать RC4 появилась в SSL/TLS Deployment Best Practices недавно.
зашел на www.apple.com/ через Google Chrome: используется TLS 1.2, AES-256-CBC with SHA1 for message auth.
А на developer.apple.com — RC4.
я эти данные еще раз перепроверил, aes-128-cbc-hmac-sha1 всегда быстрее, чем rc4-hmac-md5 при AES-NI
Это интересно, т.к. взятые отдельно sha1 и md5 примерно равны. В любом случае у вас тоже нет разницы в 170%.
В любом случае у вас тоже нет разницы в 170%

Это зависит от модели процессора с AES-NI, версии openssl, ключей сборки openssl, размера блока и т.п.
В некоторых случаях отрыв в производительности будет и ровно 170% и даже больше.

кроме того, RC4 is seriously broken и поэтому больше не рекомендуется к использованию:

Disable RC4
The RC4 cipher suite is considered insecure and should be disabled. At the moment, the best
attacks we know require millions of requests, a lot of bandwidth and time. Thus, the risk is still
relatively low, but we expect that the attacks will improve in the future.

цитата из SSL/TLS Deployment Best Practices
Для тех, кто зашёл сюда в 2016, поменяйте
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
на
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE-2014-3566)

Чтобы защититься от CVE-2014-3566.
Only those users with full accounts are able to leave comments. Log in, please.