Поиск по сайту:

Реализация SSL Perfect Forward Secrecy на веб-сервере NGINX


На этой странице

  1. Дальше: внедрение строгой транспортной безопасности HTTP (HSTS) с длительным сроком действия
  2. Поздравляем!
  3. Ссылки:

В этом HOW-TO описывается процесс реализации Perfect Forward Secrecy с веб-сервером NGINX в системах Debian и Ubuntu. Этот процесс можно легко адаптировать к другим системам GNU/Linux.

Короче говоря, совершенная прямая секретность гарантирует: \... что компрометация одного сообщения не может привести к компрометации других, а также что не существует единственного секретного значения, которое может привести к компрометации нескольких сообщений. дополнительную информацию см. на странице http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Когда в начале 2014 года была обнаружена уязвимость Heartbleed в OpenSSL, стало ясно, что PFS является обязательным условием для любой системы, которая серьезно использует SSL/TLS.

Если вы хотите сравнить свои результаты с моими, мою эталонную реализацию можно протестировать на https://indietorrent.org.

Без лишних слов давайте настроим NGINX для реализации PFS.

Перейдем в каталог конфигурации NGINX:

cd /etc/nginx/

Нам нужно сгенерировать параметры Диффи-Хеллмана, которые являются достаточно сильными. Некоторые утверждают, что 4096 бит — это излишество и вызовет чрезмерную нагрузку на ЦП системы, но с современными вычислительными мощностями это кажется достойным компромиссом. Дополнительные сведения см. в разделе «Ссылки» ниже.

openssl dhparam -out dh4096.pem 4096

Удобно иметь этот файл конфигурации, специфичный для конкретной задачи, разделенный на части во включаемом файле; это упрощает реализацию PFS в большом количестве систем.

vi /etc/nginx/perfect-forward-secrecy.conf

Вставьте следующее в вышеуказанный файл:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
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 !MEDIUM";
ssl_dhparam dh4096.pem;

Измените конфигурацию NGINX, включив указанный выше файл, вставив следующую строку в основной файл конфигурации NGINX (по умолчанию /etc/nginx/nginx.conf) внизу (и внутри) Блок http {}:

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# This MUST come AFTER the lines that includes .../sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.
include perfect-forward-secrecy.conf;

Перезапустите NGINX, чтобы изменения вступили в силу:

service nginx restart

Если тест на https://www.ssllabs.com/ssltest/analyze.html отображает Возобновление сеанса (кэширование) Нет (идентификаторы назначены, но не приняты) красным цветом, а сервер реализует SNI, добавьте следующее в верхний уровень Блок http {} (т. е. добавьте в nginx.conf чуть ниже того места, где мы делали предыдущие добавления):

# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Снова перезапустите NGINX, чтобы изменения вступили в силу:

service nginx restart

Приведенный выше тест больше не должен сообщать об этой проблеме (даже несмотря на то, что проблема не снижает общую оценку теста).

Двигаясь дальше: реализация строгой транспортной безопасности HTTP (HSTS) с длительной продолжительностью

Это несложно, и оно того стоит, при условии, что:

  1. Вы хотите принудительно использовать SSL для всех ресурсов любого хоста, для которого установлен этот заголовок (т. е. для каждой страницы рассматриваемого веб-сайта).
  2. Вы можете жить без возможности принимать и игнорировать предупреждения SSL для любого ресурса, запрошенного с любого хоста, для которого установлен этот заголовок, например \Несоответствие доменного имени\ и т. д. Сама природа HSTS заключается в том, что состояния предупреждений и ошибок, относящиеся к сертификату SSL, не могут быть переопределены.

Я искал в Интернете информацию о том, может ли установка этого заголовка иметь непредвиденные последствия в браузерах, которые не поддерживают заголовок, и не хватило. Но я смог развеять свои опасения, протестировав эту реализацию, например, в Internet Explorer 6, а браузеры, в которых HSTS не реализован, просто игнорируют заголовок. Идеально!

Просто добавьте следующие строки в конец /etc/nginx/perfect-forward-secrecy.conf и сохраните изменения:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# This will prevent certain click-jacking attacks, but will prevent
# other sites from framing your site, so delete or modify as necessary!
add_header X-Frame-Options SAMEORIGIN;

Перезагрузки (вместо перезапуска) будет достаточно, чтобы заставить NGINX принять эти конкретные изменения:

service nginx reload

Можно убедиться, что HSTS работает должным образом, протестировав свою реализацию на странице https://www.ssllabs.com/ssltest/analyze.html. Если HSTS реализован правильно, вы должны увидеть зеленую рамку чуть ниже вашей оценки, указывающую: «Этот сервер поддерживает HTTP Strict Transport Security с длительной продолжительностью. Оценка установлена на A+».

Поздравляем!

Теперь у вас есть одна из самых безопасных реализаций SSL/TLS в Интернете.

Использованная литература:

  • https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Авторское право © 2014 Бен Джонсон