Реализация SSL Perfect Forward Secrecy на веб-сервере NGINX
На этой странице
- Дальше: внедрение строгой транспортной безопасности HTTP (HSTS) с длительным сроком действия
- Поздравляем!
- Ссылки:
В этом 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) с длительной продолжительностью
Это несложно, и оно того стоит, при условии, что:
- Вы хотите принудительно использовать SSL для всех ресурсов любого хоста, для которого установлен этот заголовок (т. е. для каждой страницы рассматриваемого веб-сайта).
- Вы можете жить без возможности принимать и игнорировать предупреждения 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 Бен Джонсон