Для защиты объектов от несанкционированного доступа уже реализован не один десяток решений, который в той или иной мере обеспечивает состояние защищенности, как самих ресурсов, так и каналов связи.
Одними из интересных можно назвать протоколы шифрования, они позволяют организовать защищенное соединение, аутентифицировав перед этим пользователей. В данном материале рассмотрим инструмент, который позволяет организовать его работу!
Что такое OpenSSL?
Введем основные понятия, SSL – это шифрованный протокол, который организует соединение на основе ассиметричных ключей и публичной инфраструктуры открытых. Зачастую он используется в вебе, как дополнение к HTTP протоколу, и позволяет организовать HTTPS-соединение.
Чтобы в дальнейшем было понятно, какие ключи и сертификаты будут сформированы, кратко рассмотрим алгоритм работы SSL:
- Клиент отправляет Client Hello веб-серверу;
- Сервер получив пакет, направляет Server Hello со своим сертификатом и открытым ключом;
- Клиент проверяет подпись на сертификате, где внутри него лежит публичный ключ сервера;
- Если все сошлось публичным ключом сервера шифруется пакет и направляется к веб-серверу для создания единого симметричного ключа. Это происходит с целью повышения скорости обработки сетевого трафика. После чего соединение считается установленным и начинается коммуникация.
А OpenSSL это открытая криптографическая библиотека, которая позволяет создавать сертификаты, открытые/закрытые ключи, формировать заявки на подпись сертификата, проверяет подписи и реализует прочий функционал для корректной работы SSL-соединения.
Классически на Linux дистрибутивах уже есть предустановленный пакет, если нет, то установите командой:
sudo apt install openssl 
Чтобы знания имели прикладной характер, рассмотрим на примере, где нам необходимо организовать сетевое соединение по SSL.
Создание ключей шифрования
Фактически данная библиотека предоставляет возможности не только для SSL, но и для собственного использования, к примеру генерации ассиметричных ключей:
openssl genpkey -algorithm RSA -out private.key -aes256 Данный вариант наиболее безопасно создаст ключ, так как будет дополнительно шифрован AES-256, где при каждом желании использовать ключ необходимо вводить пароль. Однако в веб-серверах зачастую указывают ключи без доп.шифрования с целью автоматизации процесса:
openssl genpkey -algorithm RSA -out /etc/nginx/keys/subkeys/private.key 
Чтобы проверить созданный ключ на корректность будем использовать команду проверки:
sudo openssl rsa -in /etc/nginx/keys/subkeys/private.key Кроме функционала описанного выше в инструменте, так же присутствуют функции шифрования и расшифровки, проверки ключей.
Создание Certificate Sign Request
Фактически ранее созданный ключ будет использоваться, как подписанный CA для аутентификации, при соединении, так и для шифрования. Чтобы наш узел мог быть верифицирован механизмом электронной подписи, Certificate Authority базой клиента, необходимо получить подпись.
Фактически алгоритм работает так: у нас есть закрытый ключ и ему соответствует только один открытый, закрытым шифруется хеш сертификата и передается клиенту, тот из своей доверенной базы ищет открытый ключ и с помощью него расшифровывает, затем сравнивает хеши. Который нашел из подписи и сделал сам, пропустив сертификат через однонаправленную функцию хеширования. После чего сможет утверждать, что публичный ключ внутри сертификата для шифрования верный!
Сформируй запрос на подпись:
sudo openssl req -new -key /etc/nginx/keys/subkeys/private.key -out /etc/nginx/keys/subkeys/request.csr Но так же есть возможность создать новый ключ:
sudo openssl req -new -newkey rsa:2048 -nodes -keyout end_entity.key -out request.csr 
Где каждая опция имеет свое значение:
- new: Указывает, что создается новый CSR;
- key private.key: Указывает файл с приватным ключом;
- out request.csr: Сохраняет CSR в файл request.csr.
Что делать с CSR? После создания CSR:
- Отправьте файл request.csr в Центр сертификации (CA) (например, Let’s Encrypt, DigiCert, GlobalSign);
- CA проверит вашу информацию и выдаст SSL/TLS сертификат.
Но что если вам нужен самоподписной сертификат?
Как создать самоподписной сертификат?
Обычно такой вид сертификата используется в локальных корпоративных сетях, с целью обеспечения безопасного соединения между узлами и сегментами сети. Единственное, что за пределами периметра он работать не сможет, так как не был подписан общедоверенными CA.
Для его создания используем команду:
openssl req -x509 -new -key /etc/nginx/keys/private.key -out /etc/nginx/keys/certificate.crt -days 365
Где опции и аргументы выполненной команды значат:
- -x509: Указывает, что создается самоподписанный сертификат (в формате X.509);
- -new: Создает новый запрос на сертификат;
- -key private.key: Указывает файл с приватным ключом;
- -out certificate.crt: Сохраняет сертификат в файл certificate.crt;
- -days 365: Устанавливает срок действия сертификата (365 дней).
Чтобы подписать парой ключей CA ваш CSR необходимо выполнить команду:
sudo openssl x509 -req -in request.csr -CA ca_certificate.crt -CAkey ca_private.key -CAcreateserial -out signed_certificate.crt -days 365 -sha256 На входе поступает ваш signing request, а на выходе уже подписанный сертификат закрытым ключом CA.
Таким образом, после манипуляций выше вы сможете использовать свой конечный сертификат для подтверждения аутентичности и безопасной передачи данных, такая концепция может работать для любого субъекта сети. В вебе, в VPN-решениях, где необходимо аутентифицировать клиента.
Настроим сервер и клиентов
Для демонстрации работы мы взяли кейс с веб-сервером, перейдем в его конфигурацию и укажем наш новый, выданный сертификат и закрытый ключ:
server {
listen 80;
server_name example.com;
return 301 https://$host;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/keys/subkeys/certificate.crt;
ssl_certificate_key /etc/nginx/keys/subkeys/private.key;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
server_name example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
}
А корневой сертификат, ключами которого подписали конечный необходимо разместить на клиентах, где будут открывать браузер. Обратите внимание, что у них кроме наличия CA в корне, есть ряд требований к проверке: наличие цепочки PEM сертификатов, полей SAN, даты действия и многое другое.
Установим сертификат CA для Windows, для этого от имени Администратора запустим файл certificate.crt и добавим его в корневые:
А так же для Linux подобных систем можно поместить файл формата .crt в директорию для его инсталляции:
sudo cp certificate.crt /usr/local/share/ca-certificates/ #or choose another directory sudo cp certificate.crt /etc/ssl/certs/ После чего можем перейти на наш ресурс и проверить корректность выстроенного соединения:
Отлично, защищенное соединение установлено, а узел перед подключением проверен. Однако даже, при отображении подобного статуса ваше соединение может быть перехвачено, путем заражения вашего корневого центра внутри АРМ, недоверенным вами сертификатом. Будьте бдительны к процессам затрагивающим данную сенситивную директорию! Для выполнения тестов, вы можете использовать изолированную среду VPS сервера, на любой из двух платформ vStack cloud или же VMware cloud. Нажмем на кнопку Создать сервер и выберем конфигурацию, подходящую под наши задачи, затем нажмем кнопку Создать.
Потребуется некоторое время для развертывания серверных мощностей. После чего вы можете подключиться любым из удобных способов.
