Пользователь
0,1
рейтинг
30 сентября 2013 в 19:58

Разработка → Настраиваем HTTPS-сервер на nginx из песочницы tutorial

Для чего я это пишу?


В последнее время в связи с кучей факторов (АНБ, DPI с рекламой и другое) у меня начала просыпаться паранойя и я подумал полностью перевести свой небольшой сайт на https. На хабре было несколько статей с техническими подробностями работы SSL/TLS, однако поискав информацию на тему настройки https-вебсервера обнаружил традиционное деление статей — либо это статьи «Делайте вот так», где просто даны настройки без каких-либо разъяснений и вариантов использования, либо это большие теоретические статьи, где обсуждаются различные схемы использования, но без практически применимых готовых вариантов. На хабре была статья о настройке, однако в ней нет информации про DH-кодировки, да и некоторые параметры не описаны. Подумал, что стоит упорядочить найденное в виде статьи, которая будет полезна тем, кто хотел бы развернуть https у себя на сервере, но не слишком углубляться в дебри SSL.

Повествование будет вестись с учетом того, что веб-сервером выступает nginx (и в одном месте будет параметр для php-fpm).

Сертификат


У меня уже был сертификат от StartSSL. О нем уже писали на хабре, так что на этом шаге задерживаться не буду. Скажу только, что в течении первых двух-трех дней браузеры, проверяющие сертификат на сервере, могут на него ругаться (у меня такое происходило с Opera 12 и Firefox), видимо у StartCom кеши валидных сертификатов обновляются не так часто. Про установку же будет сказано ниже

О вариантах настройки


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

В общем случае есть два актуальных на данный момент варианта настройки — с Forward Secrecy и без него. При настройке различие только в наборе кодировок (директива ssl_ciphers), однако тут стоит задуматься, что же вы хотите от https.

О Forward Secrecy можно почитать скажем тут. В двух словах, суть заключается в том, что для актуального на данный момент алгоритма RC4 ключи сессии генерируются на основе приватного ключа сервера. Таким образом, если приватный ключ будет скомпрометирован, появится возможность расшифровать все сессии (если они были записаны). В случае же использования DH-кодировок, каждая сессия имеет свой набор ключей, которые сессии никак не зависят от приватного ключа. Однако в этом случае тратится гораздо больше процессорного времени на хендшейк, что увеличивает нагрузку и время открытия страницы.

Тут стоит задуматься, для чего нужен https конкретно у вас на сайте. При большом количестве посетителей использование DH-алгоритмов шифрования может прилично увеличить нагрузку (которая в любом случае повысится при переходе на HTTPS), в некоторых случаях придется увеличить тариф на VDS и т.п. В большинстве случаев RC4 достаточно, однако многим хочется чтобы все было «по высшему классу», так почему бы не сделать, если ресурсы позволяют?

Настройка nginx


В результате настройки у меня сформировался приблизительно такой конфиг, суть параметров поясню ниже.

В секции http необходимо добавить:
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_stapling on;
resolver 8.8.8.8;


Секция server же получится приблизительно такая:
server {
    listen       443 ssl;
    server_name  www.site.ru;
    .......

    keepalive_timeout   60;
    ssl_certificate      certificate_bundled.crt;
    ssl_certificate_key  privatekey.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers  "HIGH:!RC4:!aNULL:!MD5:!kEDH";
    add_header Strict-Transport-Security 'max-age=604800';

	.......
    location ~ \.php$ {
	.......
        fastcgi_param HTTPS on; # Для php-fpm
	.......
    }
}


В данном примере не используются DH-алгоритмы, т.е. нет Forward Secrecy. Из улучшений тут можно опустить поддержку SSLv3 (убрав его из ssl_ciphers), таким образом перестанет поддерживаться IE 6 и ниже, поскольку он не поддерживает TLS, а так же увеличить время STS, но об этом ниже.
Без SSLv3 такая настройка дает оценку 100-95-100-90 в тесте SSL.

Пройдемся по параметрам


ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;

«Задаёт тип и размеры кэшей для хранения параметров сессий.» (nginx.org) Кеш необходим для возможности повторного использования ключей сессии, таким образом при установлении нового соединения будут использоваться старые ключи, т.е. не будет повторно производиться хендшейк. Особенно актуально при использовании кодировки DHE (например в бразуере Opera 12), поскольку время загрузки страницы со всеми элементами сильно увеличивается при отсутствии кеша, а DHE еще и использует больше ресурсов и времени (относительно EECDH и RC4). Параметр shared задает общий для всех рабочих процессов nginx кеш, 10m — объем кеша (10 МБ, при этом 1 МБ~4000 сессий, таким образом при этих настройках можно хранить до 40 тысяч сессий), 5m — таймаут сессии в кеше (5 минут).

ssl_prefer_server_ciphers on;
«Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские.» (nginx.org) — клиентские шифры (CBC) уязвимы к некоторым типам атак.

ssl_stapling on;
Позволяет серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. ЗДесь имеются ввиду ответы о валидности сертификата (при проверке на отозванность). С точки зрения безопасности пользователя не важно, кто передает ответы — веб-сервер или сервер CA — ведь ответ в любом случае подписан и валидность ответа тоже можно проверить, а ответ включает в себя свой срок действия.
Для работы этой функции нужно указать DNS-сервер, что и делается директивой resolver.

keepalive_timeout — думаю в описании не нуждается, не стоит выключать или ставить слишком малым для уменьшения нагрузки из-за повторного установления соединения.

ssl_certificate и ssl_certificate_key указывают на файл сертфиката и файл приватного ключа для него. Так как я рассказываю на примере сертификата от StartSSL, то здесь допущу небольшой комментарий относительно инструкций StartSSL по установке сертификата — не нужно добавлять сертификат Root CA в обобщенный файл сертификата, поскольку это не имеет смысла и только увеличивает, хоть и не на много, размер передаваемых данных. Достаточно иметь в файле последовательно личный сертификат и сертификат промежуточного центра сертификации. Готовый файл сертификата для nginx (для сетификата StartSSL) можно получить следующей командой:
cat certificate.crt sub.class1.server.ca.pem > certificate_bundled.crt

Где ваш сертификат — certificate.crt, а промежуточный сертификат — www.startssl.com/certs/sub.class1.server.ca.pem

add_header Strict-Transport-Security 'max-age=604800';
Strict-Transport-Secutiry — заголовок, указывающий браузеру на то, что сайт доступен только по https. Это предотвращает возможность перехода обратно на http-версию для последующей атаки через незашифрованное соединение. Кстати данный параметр еще удобен тем, что при наличии в коде страницы «забытого» подключения ресурса (картинки/скрипта/стиля/...) с того же сайта по http, браузер сам пойдет на https-версию и не будет ругаться на частично незашифрованное соединение. Конечно же это не сработает для внешних ресурсов. Время — неделя. Многие рекомендуют ставить 1 год, однако в случае решения в будущем отказаться от использования https это может доставить проблемы некоторым пользователям. Время обновляется при каждой передаче этого заголовка, т.е. при каждом заходе на сайт.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Указывает поддерживаемые протоколы. SSLv2 и v3 имеют критические уязвимости.

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

Forward Secrecy


Для включения Forward Secrecy можно использовать например такой набор шифров:
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";


Кроме того, необходимо настроить приоритет шифров OpenSSL:
openssl ciphers -V 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA256 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

В данном варианте не запрещается использование RC4 для сохранения совместимости с некоторыми браузерами, однако не так давно обнаружились уязвимости и в нем, хоть и практически трудно реализуемые.

Для усиления шифрования можно увеличить стойкость DH-шифров, создав файл параметров DH-шифров (создание файла займет некоторое время!), скажем длинной 4096 бит:
openssl dhparam -out dh4096.pem 4096

И добавив в конфиг nginx директиву
ssl_dhparam dh4096.pem;

Это можно делать для скажем для веб-интерфейсов управления сервером/службами, однако хендшейк будет происходить еще дольше, поэтому не стоит делать это на обычном сайте.

Про CDN-сервисы


В обсуждении инструкций по настройке Forward Secrecy было замечено, что по крайней мере CDN Amazon CloudFront не поддерживает обмен с вашим сервером в DH-кодировках, да и RC4 вроде тоже, что не радует. Возможно что и с другими CDN тоже не все идеально, но я лично пока с ними не сталкивался, поэтому ничего сказать не могу.

Полезные ссылки


Тестирование настроек https-вебсервера
Настройки Apache и nginx для Forward Secrecy
@KorDen32
карма
27,0
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (55)

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

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

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

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


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

    , то
    ssl on;
    

    не нужно.
  • +3
    У Qualys SSL Labs, на которого ссылались в статье пять раз, есть регулярно обновляемый полезнейший документ SSL/TLS Deployment Best Practices
  • 0
    Скажу только, что в течении первых двух-трех дней браузеры, проверяющие сертификат на сервере, могут на него ругаться (у меня такое происходило с Opera 12 и Firefox), видимо у StartCom кеши валидных сертификатов обновляются не так часто.
    Не очень понял о чём тут речь.
    • 0
      А вот выше уже ответили, не заметил.
      Тогда другой вопрос — как именно ругались браузеры? Может просто промежуточного сертификата в цепочке не хватало?
      • 0
        Что-то вроде «Ошибка OCSP», сейчас уже точно не вспомню точно, промежуточный сертификат был. Ну и выше уже тоже прокомментировали подобное поведение.
      • 0
        Нашел старый скриншот… Конкретно Firefox ругался «OCSP-сервер не имеет статуса этого сертификата. (Код ошибки: sec_error_ocsp_unknown_cert)», так что вышенаписанное верно.
  • 0
    А как у вас на Qualys такие цифры? Можно ссылку на реальный сервер?

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

    image
    • 0
      А лучше может и не получиться ;-)
      Например: community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what#comment-3119
      • 0
        Это я понял, RC4 не отключить, иначе BEAST-уязвимость.

        Но автор пишет:
        Без SSLv3 такая настройка дает оценку 100-95-100-90
        • 0
          Ну и что, стремится любой ценой получить 100 попугаев, или же обеспечить поддержку браузеров, не понимающих TLS? Решать вам)
          • 0
            «Я стремлюсь» или «вы стремитесь получить… или обеспечить...»? Тогда стремиться, а то не совсем понятно к кому комментарий
            • 0
              Спасибо за исправление, но оно сути не меняет)
    • 0
      Это с RC4, но без SSLv3 (100-95-100-90):
      www.ssllabs.com/ssltest/analyze.html?d=paranoidsecurity.nl

      А это с RC4 и SSLv3 (100-90-100-90):
      www.ssllabs.com/ssltest/analyze.html?d=myibidder.com
  • 0
    ээм а можно вопрос?
    есть сервер на котором несколько виртуальных хостов.
    для одного их них требуется 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 результаты равны
    • 0
      Увы, это невозможно в обычном случае. Можно сделать еще один сервер где идет default_server для 443 порта и return 444; однако тогда сайт будет открываться только в браузерах, поддерживающих SNI, т.к. если браузер не передает имя хоста в начале сессии, то nginx будет считать что запрошен дефолтный (где соединение закрывается), а не нужный вам сайт.
      • +2
        Если отбросить IE для Windows XP и экзотику то SNI работает везде.
  • 0
    cat certificate.crt sub.class1.server.ca.pem > certificate.crt
    Ш_Щ
    • –1
      Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном общеизвестным центром сертификации, в то время как другие браузеры без проблем принимают этот же сертификат. Так происходит потому, что центр, выдавший сертификат, подписал его промежуточным сертификатом, которого нет в базе данных сертификатов общеизвестных доверенных центров сертификации, распространяемой вместе с браузером. В подобном случае центр сертификации предоставляет “связку” сертификатов, которую следует присоединить к сертификату сервера. Сертификат сервера следует разместить перед связкой сертификатов в скомбинированном файле:

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


      nginx.org/ru/docs/http/configuring_https_servers.html
      • +3
        Вот именно что, cat www.example.com.crt bundle.crt > www.example.com.chained.crt
        А не cat certificate.crt sub.class1.server.ca.pem > certificate.crt
        Минусуют видимо тупые.
        • –1
          Это непринципиальная опечатка. Стоило просто написать автору в личку.
          • +2
            Непринципиальной она была бы если б не убивала добытый сертификат.
            • 0
              Во-первых, выстрелить в ногу в большинстве случаев вам не даст система:
              -> % LANG=C cat f1 f2 >f1
              cat: f1: input file is output file
              

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

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

                Во-вторых и в-третьих уйдет время на дебаг (хоть и короткий) и эти самые «заново» и re-issue.
                • –1
                  Вам не кажется, что полезно различать комментаторов и автора статьи?
                  • +2
                    Просто Вы так яростно защищали техническую неаккуратность данной статьи, что я не заметил, что автор другой.
                • 0
                  Упс, переоптимизировал… Что-то мне казалось что все будет нормально, однако да…
                  [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

                  Исправил, спасибо
  • 0
    В CentOS/Fedora/RHEL нет поддержки ECC-алгоритмов в openssl, к сожалению. Можно использовать обычный kEDH.
    • +1
      можно самому собрать 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
      ...
      

      • 0
        Или пересобрать openssl, не накладывая патчи, удаляющие EC. В оригинальном spec'e вырезаются IDEA, RC-5, EC с помощью скрипта hobble-openssl.
        • 0
          если пересобрать пакет 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.
          • 0
            Я с вами полностью согласен.

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

            И второй момент: не всем нужен такой уровень security. Для защиты формочки ввода пароля на личном bugzilla/redmine — он, как правило, не нужен.
  • +1
    Для включения 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»
    • +1
      в вашей статье зачем-то рекомендуется использовать RC4


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

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

    • 0
      Не всем нужен идеальный уровень безопасности, а нагрузка возрастает. 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…
  • +1
    … для тех кто хочет сэкономить ресурсы можно поставить 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.
    • 0
      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?
  • 0
    У них что-то не в порядке с производительностью 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 недавно.
  • 0
    зашел на 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%.
    • 0
      В любом случае у вас тоже нет разницы в 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
  • 0
    Для тех, кто зашёл сюда в 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.

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