Ssl dhparam что это

Зачем указывают ssl_dhparam в конфиге nginx? Какой риск если его убрать из конфига?

Теперь о ssl_dhparam /etc/pki/nginx/dhparam.pem; — это нужно, чтобы у нас заработал Forward Secrecy. Прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить лишь доступ к данным, защищенным лишь этим ключом. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то еще ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей.

С этого объяснения мне совершенно не понятно

Указание ssl_dhparam делает доступным для использования в nginx семейство алгоритмов DHE/EDH. Как раз тех, что используют Forward Secrecy, о которых пишется в вашей цитате. Если в двух словах, то при использовании алгоритмов с FS злоумышленник не сможет расшифровать перехваченный трафик, даже если завладеет приватным ключом сервера.

Маленькое значение этого простого числа делает возможным атаку logjam на TLS, поэтому следует генерировать большое. 4096 бит будет достаточно с запасом.

Команда для генерации файла dhparam:

art style, ky0 скорее говорит не о конкретно банковском ПО, а о вообще любом ПО на java 6. Суть в том, что java до 7 версии включительно поддерживала dhparam не больше 1024 бит. В итоге java клиент согласовывает алгоритм DHE как самый лучший из поддерживаемых, но не может им воспользоваться из-за слишком большого dhparam на сервере. И будет большой удачей, если на стороне клиента найдется специалист, способный зафиксировать другой поддерживаемый алгоритм шифрования. При условии, что ПО в принципе позволяет сделать такие настройки.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Настраиваем Nginx для работы по HTTPS (SSL) с сертификатами Let’s Encrypt

Мы не будем касаться первоначальной настройки, будем считать, что веб-сервер уже настроен вами и работает. Наш экземпляр был настроен по инструкции Настраиваем веб-сервер на базе Nginx + PHP-FPM в Debian / Ubuntu Server и мы в дальнейшем будем придерживаться его конфигурации. В данном примере используются Nginx 1.17, PHP 7.3 и MariaDB 10.3 в среде Debian 10, но с небольшими поправками данная статья может использоваться для любого основанного на Debian дистрибутива.

Будем считать, что все конфигурационные файлы сайтов располагаются в /etc/nginx/sites-available, символические ссылки на активные сайты в /etc/nginx/sites-enabled, а шаблоны настроек в /etc/nginx/templates. Если вы используете иное расположение конфигурационных файлов, то это следует учитывать при выполнении описанных ниже действий.

В качестве примера будем рассматривать некий сайт example.org для которого будет настроена минимальная конфигурация следующего вида и установлена популярная CMS WordPress:

Прежде всего создадим новый шаблон для работы с Let’s Encrypt:

Откроем его и внесем следующий текст:

И подключим его в конфигурационный файл нашего сайта, добавив в самый конец основной секции server строку:

Также не забудем создать указанную нами в шаблоне директорию и сделать ее владельцем веб-сервер:

Проверим правильность конфигурации nginx:

и перезапустим веб-сервер:

Затем установим certbot, в современных дистрибутивах достаточно выполнить:

Более подробную информацию по установке и работе с certbot вы можете получить в нашей статье: Получаем сертификаты Let’s Encrypt при помощи Certbot

Пакет не требует установки и сразу готов к работе. Перед тем как получать сертификаты следует убедиться, что к серверу есть доступ из сети интернет и доменное имя вашего сайта указывает именно на этот сервер. В любом случае сначала лучше произвести пробное получение сертификата:

Ключ —dry-run указывает на тестовый режим, —webroot задает используемый плагин, в данном случае работающий с уже имеющимся веб-сервером. Опция -w указывает рабочую директорию, которую мы настроили ранее, а через опцию -d задаются домены и поддомены, для которых мы хотим получить сертификат. Если все прошло успешно, то вы получите лаконичное сообщение:

Убедившись, что все работает нормально, можно получить рабочие сертификаты, для этого еще раз запустим приведенную выше команду, но уже без ключа —dry-run:

Символические ссылки на полученные сертификаты хранятся в /etc/letsencrypt/live, это позволяет использовать один и тот же путь несмотря на постоянное обновление сертификатов раз в 90 дней. Настройки продления для каждого сайта расположены в /etc/letsencrypt/renewal, откроем файл с настройками нашего домена /etc/letsencrypt/renewal/example.com.conf и внесем в секцию [renewalparams] следующую опцию:

Порядок расположения опций значения не имеет, данная настройка задает действие при успешном обновление сертификата, в данном случае это перезапуск веб-сервера nginx.

После получения сертификата настроим наш виртуальный хост на работу с ним. Для этого вернемся к конфигурационному файлу /etc/nginx/sites-available/example.org.conf и создадим в нем новую секцию server, внеся в нее следующие строки:

Первая опция предписывает использовать ssl и протокол HTTP/2 (если такая возможность поддерживается клиентом), а вот следующее за ним условие требует пояснений. Работа с HTTPS устроена таким образом, что если у сервера был запрошен по защищенному протоколу сайт, не имеющий сертификата, либо вообще произошло обращение по IP-адресу, то в ответ будет показан тот защищенный сайт, который находится первым в конфигурации. Во многих случаях такое поведение будет неожиданным для пользователя и его следует избегать. В нашем случае, при запросе узла отличного от указанного в конфиге сервер оборвет соединение без отправки данных (ошибка 444 в Nginx).

Ниже добавим пути к сертификатам и настройки SSL-сессии:

Для обеспечения режима прямой секретности нам понадобится файл параметров Диффи-Хелмана, создадим его:

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

Добавим путь к нему в наш конфигурационный файл:

Следующую опцию пока следует закомментировать:

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

Следующие строки отвечают за поддержку OCSP Stapling, что позволяет ускорить проверку сертификата клиентом и ускорить загрузку сайта.

Ниже скопируем из основной секции сервер оставшиеся параметры и немного отредактируем их:

Проверим конфигурацию и перезапустим веб-сервер:

После чего убедимся, что сайт работает по защищенному протоколу HTTPS:

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

После того, как вы убедились, что ваш сайт отлично работает в защищенном режиме, внесем последние штрихи. Прежде всего включим режим HSTS, раскомментировав опцию:

Затем приведем к следующему виду секции:

Которые обеспечат перенаправление всех HTTP запросов на HTTPS версию сайта.

Еще раз проверим конфигурацию и перезапустим веб-сервер:

На этом настройка Nginx для работы по защищенному протоколу с использованием сертификатов Let’s Encrypt закончена, но приведенная нами конфигурация не является истиной в последней инстанции, технологии развиваются и то, что еще сегодня считалось отличным, завтра может оказаться недостаточным. Поэтому советуем время от времени изучать последние рекомендации и обновлять конфигурацию собственного сервера.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Nginx и https. Получаем класс А+

Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.

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

Вот что у меня получилось:

В первой секции всё вроде понятно, любой вход по http с любым URI редиректит с этим-же URI в схему https.

Начнём разбор секции server для https. Директивой listen 443 ssl spdy; сразу включаем spdy. Вот на картинке разница:

Следущим шагом включаем ssl_stapling on; — позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. Цепочка сертификатов (доменный — промежуточный центр авторизации — корневой центр авторизации) может содержать 3-4 уровня. И на каждый уровень браузер должен устанавливать соединение и получать сертификат. Можно отправить все сертификаты (включая промежуточный: именно за этим была настройка TCP-окон отправки, чтобы цепочка сертификатов гарантированно поместилась в в одну пересылку пакетов) разом, тогда браузер проверит всю цепочку локально, а запросит только корневой (который в большинстве случаев уже находится на клиенте). Для работы этой функции обязательно описать resolver — у меня поднят свой собственный DNS сервер, поэтому в качестве значения указан 127.0.0.1, Вы можете указать 8.8.8.8, но многие в последнее время на него ругаются. Что такое ssl on; я думаю нет смысла рассказывать.

Далее директивами ssl_certificate и ssl_certificate_key указываем пути к полученным через StartSsl сертификатам. У вас уже есть 3 файла: domain.ru.key, domain.ru.crt и sub.class1.server.ca.pem. Копируем ключи в ( моём случае ) /etc/pki/nginx.

Не забываем, что pem файл для nginx должен быть смержен с сертификатом CA ( Должно получиться из 3х — 2 файла. ):

Теперь о ssl_dhparam /etc/pki/nginx/dhparam.pem; — это нужно, чтобы у нас заработал Forward Secrecy. Прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить лишь доступ к данным, защищенным лишь этим ключом. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то еще ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей.

Сгенерировать ключ можно так:

Далее несложные настройки ssl_session_timeout 24h; и ssl_session_cache shared:SSL:2m;, которые не требуют особенных описаний — срок истечения сессии и размер памяти, выделяемой для хранения кеша — у меня бложик маленький, поэтому 2 Мб вполне достаточно.

Дальше — важные параметы: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; и ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; — тут мы указываем, что мы желаем только TLS и второй строкой выжигаем калёным железом все SSL. В свете последних фейлов с SSL — очень актуально, что и Вам советую. Ну и директивой ssl_prefer_server_ciphers on; принуждаем nginx это всё строго соблюдать.

Директива add_header Strict-Transport-Security «max-age=31536000;»; указывает браузерам сколько они должны помнить данные требования безопасности для моего домена. В данном случае — 1 год. Кстати, если директиву написать вот так: add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload»;, то данные условия будут применимы ко всем доменам третьего и выше уровня вашего домена. Тут будте осторожны! Я изначально описал именно так, но так, как StartSsl выдаёт сертификаты на ограниченное количество поддоменов, я наткнулся на невозможность даже попасть на свои поддомены, которые обслуживают разнообразные админки, работали только те, на которые были выписаны trusted сертификаты. Поэтому я для себя выбрал первый вариант.

Далее — add_header Content-Security-Policy-Report-Only «default-src https:; script-src https: ‘unsafe-eval’ ‘unsafe-inline’; style-src https: ‘unsafe-inline’; img-src https: data:; font-src https: data:; report-uri /csp-report»; — я толком глубоко ещё не изучил свойства данного заголовка. Content Security Policy (CSP) — новый стандарт, определяющий HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру белый список хостов, с которых он может загружать различные ресурсы.

Временно я взял данную строку из статьи Яндекса про применение у них CSP, почитать подробно можно тут: http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

Вот вроде-бы и всё. Несколько ссылкок, где можно проверить результаты своих и чужих трудов:

Источник

It’s a blog. Just a blog!

Создание DH (Diffie Hellman) сертификата

Если вы в данный момент занимаетесь настройкой SSL сертификата для вашего домена, то скорее всего уже слышали о том, что безопасность сайта можно улучшить не только SSL сертификатом, но и специальным ключом, использующий алгоритм Диффи Хельмана. Данный ключ может использоваться не только в работе сайта, но и в любом другом случае, где применяются технологии шифрования. Одним из ярких примеров, где применяются DH ключи является программа OpenVPN.

Ниже мы рассмотрим процесс создания DH ключа и подключения ключа к популярным веб, почтовым и VPN серверам.

(!) Все операции производятся на операционной системе Linux Centos 7.

Для создания DH (Diffie Hellman) ключа необходимо перейти в папку tmp

или любую другую удобную для вас папку, и запустить команду генерации DH (Diffie Hellman) ключа

Так как openssl используется для генерации разных видов ключей, при генерации необходимо указать параметр создания именно DH (Diffie Hellman) сертификата.

Криптостойкость ключа составляет 2048 бит, что делает ключ достаточно надежным.

Генерация ключа занимает достаточно долгое время. Во время создания ключа на экране вы сможете наблюдать примерно следующую картину

После некоторого ожидания ключ будет создан и готов для дальнейшего использования. Ниже приведены выдержки из конфигурационных файлов с указанием строк для подключение DH ключа к веб, почтовым и VPN серверам.

Для подключения DH ключа необходимо два параметра:

(1) включить безопасные шифры(чиперы)

(2) подключить ключ, который сгенерирован на предудущем этапе.

Nginx

Настройка производится в конфигурационном файле /etc/nginx/sites-enabled/example.com

(!) путь и имя конфигурационного файла может отличаться, так как Nginx позволяет производить include дополнительных конфигурационных файлов в основной.

Добавляем данные о ключе

и перезагружаем сервис

(!) Стоит обратить внимание на параметр ssl_prefer_server_ciphers on; данный парамер непосредственно включает чтение списка чиперов, а после уже идет список чиперов.

###Apache Настройка производится в конфигурационном файле `/etc/httpd/conf/httpd.conf`

(!) путь и имя конфигурационного файла может отличаться, так как Apache позволяет производить include дополнительных конфигурационных файлов в основной конфигурационный файл.

Добавляем данные о ключе

и перезагружаем сервис

Lighttpd

Настройка производится в конфигурационном файле /etc/lighttpd/lighttpd.conf

Добавляем данные о ключе

и перезагружаем сервис

Sendmail

Настройка производится в конфигурационном файле /etc/mail/sendmail.mc в секции LOCAL_CONFIG

Добавляем данные о ключе

и перезагружаем сервис

Postfix

Настройка производится в конфигурационном файле /etc/postfix/main.cf

Добавляем данные о ключе

и перезагружаем сервис

OpenVPN

Настройка производится в конфигурационном файле /etc/openvpn/server.conf

Добавляем данные о ключе

и перезагружаем сервис

(!) Включение дополнительных параметров для работы DH ключа не требуется.

(!) Для работы с DH ключом необходимо обязательно включить SSL режим работы.

(!) Списки чиперов, указанные в примерах, не являются окончательными и можгут меняться, в зависимости от текущих уязвимостей протоколов и ваших потребностей.

Источник

Правильная настройка SSL в NGINX

В данной инструкции разберем принцип правильной настройки поддержки https в веб-сервере NGINX, которая пройдет проверку безопасности с присвоением максимальной категории. Тестировать конфигурацию мы будем с помощью сервиса https://www.ssllabs.com/ssltest/ — наша задача получить категорию А:

Статья не рассчитана на новичков — вы должны понимать общие принципы настройки https в NGINX. Команды, приведенные в данном руководстве выполняются на системе Linux. Для Windows принцип настройки остается таким же, за исключением конкретных команд и путей до конфигурационных файлов.

Для достижения результата мы рассмотрим:

1. Правильный сертификат

Под этим подразумевается выполнение двух условий:

Доверенный центр

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

Для получения сертификата от правильного центра, необходимо за него заплатить или получить бесплатно от Let’s Encrypt. Купить сертификат можно у большинства хостеров или регистраторов доменных имен. Для получения бесплатного сертификата можно воспользоваться инструкцией Получение бесплатного SSL сертификата Let’s Encrypt.

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

Сертификат для домена

Заказывая сертификат, мы обязательно указываем, для какого доменного имени его будем использовать. Это обязательное требование. Например, если мы хотим настроить SSL-подключение к узлу security.dmosk.ru, то необходимо указывать именно это имя при заказе ключа безопасности. В противном случае, браузер будет выдавать нам ошибку, что сертификат выдан для другого узла.

Также мы можем заказать сертификат типа wildcard — он применим к домену и все его поддоменам. Например, в нашем случае мы можем заказать ключ для *.dmosk.ru — он будет применять для любого доменного имени 3-го уровня с корнем dmosk.ru.

2. Использование всей цепочки сертификатов

Применяя сертификат в NGINX, необходимо загрузить не только сертификат для домена, но и для всех центров сертификации — как основного, так и промежуточных. В противном случае, мы получим ошибку This server’s certificate chain is incomplete. Grade capped to B:

В случае покупки сертификата, нам отправляют все ключи в отдельных файлах. Цепочка сертификатов, как правило, идет в файле chain. Мы должны скопировать последовательность в данном файле и добавить ее к содержимому в файле с сертификатом домена — получиться файл, содержащий как последовательность для домена, так и всех центров. Назвать его можно fullchain.pem.

В случае получение бесплатного сертификата от Let’s Encrypt, мы получаем 4 файла, один из которых называется fullchain.pem — именно он и содержит все необходимые последовательности.

И так, при настройке виртуального домена в NGINX, необходимо указать путь до файла, содержащего в себе все ключи, например:

server <
listen 443;
server_name security.dmosk.ru;
ssl on;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;

* в данном примере мы настраиваем NGINX для домена security.dmosk.ru; обратите внимание, что мы указали путь до файла fullchain.pem, в котором должны находиться последовательности, как для домена, так и центров сертификации.

Не забываем перезапустить nginx:

systemctl restart nginx

3. Отключение устаревших протоколов

В случае, если наш веб-сервер поддерживает подключение с использованием устаревших протоколов безопасности, например, TLS 1.0, мы получим ошибку This server supports TLS 1.0 and TLS 1.1:

В NGINX нам необходимо перечислить протоколы, по которым разрешено подключение. Лучше всего это сделать в основном конфигурационном файле:

Внутри раздела http добавим:

* в данном примере мы указали, что разрешены подключения только по TLS версии 1.2.

Не забываем перезапустить nginx:

systemctl restart nginx

4. Задаем приоритет для серверных шифров

Нам необходимо указать, чтобы при использовании протокола TLS серверные шифры были приоритетнее, чем клиентские. В противном случае мы увидим ошибку This server does not support Forward Secrecy with the reference browsers:

Задать настройку можно в разделе http основного конфигурационного файла:

http <
.
ssl_prefer_server_ciphers on;
..
>

Не забываем перезапустить nginx:

systemctl restart nginx

5. Настройка более стойкого ключа Диффи-Хилмана

Для шифрования сессий NGINX использует DH-шифры. Если последовательность не достаточно стойкая (ниже 2048 бит), мы увидим ошибку This server supports weak Diffie-Hellman (DH) key exchange parameters:

Чтобы исправить ошибку, генерируем стойкую последовательность для Diffie-Hellman файла:

В настройках NGINX (разделе http) добавляем:

Не забываем перезапустить nginx:

systemctl restart nginx

(Опционально) Перенаправление с 80 на 443

Стоит добавить настройку для перенаправления запроса с http на https. Для этого в настройке виртуального домена в NGINX добавим:

Источник