Образовательный проект «SnakeProject» Михаила Козлова

Навигация

⇒ FreeBSD and Nix ⇐

CISCO

Voice(Asterisk\Cisco)

Microsoft

Powershell

Python

SQL\T-SQL

Общая

WEB Разработка

ORACLE SQL \ JAVA

Мото

Стрельба, пневматика, оружие

Саморазвитие и психология


Nginx ssl и tls аутентификация


Nginx ssl и tls аутентификация

SSL - Secure Socket Layer, уровень защищенных сокетов
TLS - Transport Layer Security, безопасность транспортного уровня, более поздний, основан на спецификации SSL 3.0

Безопасная передача обеспечивается с помощью аутентификации и шифрования передаваемой информации
Общая задача обоих протоколов — обеспечение защищенной передачи данных между двумя нодами через сеть интернет

Принцип работы SSL или TLS:
Поверх протокола TCP/IP устанавливается зашифрованный канал (SSL или TLS)
Внутри канала уже передаются данные по прикладному протоколу (HTTP\FTP и т.д.)

Т.е. прикладной протокол инкапсулируется в TLS/SSL, который в свою очередь инкапсулируется в TCP/IP
В итоге данные прикладного протокола передаются по TCP/IP в зашифрованном виде
Расшифровать такие данные сможет только та машина, которая установила соединение

Установка безопастного соединения:
1. Клиент устанавливает соединение например на порт с нужным сервером и запрашивает защищенное подключение
2. При установке соединения клиент предоставляет список алгоритмов шифрования, которые ему доступны
3. Сервер сверяет полученный список с доступным ему списком алгоритмов шифрования, и выбирает наиболее надежный
4. После выбора алгоритма сервер сообщает его клиенту
5. Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера
6. Клиент опционально может связаться с сервером доверенного центра сертификации, который подписал сертификат и проверить валидность
7. Генерируется сеансовый ключ для защищенного соединения:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Т.к. алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер
При использовании асимметричного шифрования используется два ключа — приватный и публичный
Публичным отправляемое сообщение шифруется, а приватным расшифровывается
Расшифровать сообщение, имея публичный, ключ невозможно
Зашифрованное соединение установлено

Запрос на подпись (CSR, Certificate Sign Request) отправляется авторизационному центру для получения подписанного серверного сертификата
Корневой сертификат авторизационного центра - подпись, подтверждающая, подписанный сертификат сервиса

Клиентский сертификат может быть сгенерирован для использования в устройствах или пользователями
Используют при двусторонней верификации:
клиент верифицирует, что сервер действительно тот, за кого себя выдает
сервер в ответ верифицирует, что клиент действительно тот, за кого себя выдает
Такое взаимодействие называется двусторонней аутентификацией
Это позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации логину и паролю

Необходимые шаги генерации сертификатов

1. Генерация корневого сертификата, подписывается сам собой, позже этим сертификатом будут подписываться остальные сертификаты
$ openssl genrsa -out root.key 2048
$ openssl req -new -key root.key -out root.csr
$ openssl x509 -req -days 36500 -in root.csr -signkey root.key -out root.pem

Мы сгенерировали сначала приватный ключ (root.key)
После запрос подписи (root.csr)
Затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат на 100 лет (root.pem)

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

Просмотр информации сертификата:
$ openssl x509 -noout -issuer -enddate -in root.pem

Серверный сертификат

Действия для подписи сертификата сервера:
1. Сгенерировать ключ
2. Сгенерировать запрос на подпись
3. Отправить CSR-файл в авторизационный центр или подписать самостоятельно

$ openssl genrsa -out server.key 2048
$ openssl req -new -key server.key -out server.csr
$ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365
$ openssl x509 -noout -issuer -subject -enddate -in server.pem

Сертификат сервера подписан, теперь известна организация, выдавшая данный сертификат
После подписи сертификат можно установить на сервер

Установка SSL или TLS сертификатов на сервер nginx

1. Скопируйте файлы .key и .pem на сервер, например директориии:
Debian - /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей
CentOS - /etc/pki/tls/certs для сертификатов и /etc/pki/tls/private для ключей

2. Прописать в конфигурацию (разрешены подключения только по TLS версий 1.2 и 1.3):
server {
        listen 443;
        server_name test.domain;
        ssl on;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_certificate /etc/ssl/certs/server.pem;
        ssl_certificate_key /etc/ssl/private/server.key;
        ...
}

Создание клиентского сертификата

Почти аналогичная процедура:
$ openssl genrsa -out client.key 2048
$ openssl req -new -key client.key -out client.csr
$ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365
$ openssl x509 -noout -issuer -subject -enddate -in client.pem

Опционально формат PKCS12:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out client.p12

Установка клиентского сертифика на сервер nginx:
server {
        ssl_client_certificate /etc/ssl/certs/clientroot.pem;
        ssl_verify_client optional;
        ssl_verify_depth 2;
        ...
}

Проверка

На стороне сервера запускаем "прослушку" порта с помощью openssl:
$ openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Делаем запрос:
$ curl -k https://192.168.1.1:443
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx</center>
</body>
</html>

curl https://192.168.1.1:443 --cacert root.pem --cert client.pem --key client.key
Hello World!

Cерверный сертификат работоспособен

Поддержать автора и канал: https://yoomoney.ru/to/410012210709233

 


Комментарии пользователей

Эту новость ещё не комментировалиНаписать комментарий
Анонимам нельзя оставоять комментарии, зарегистрируйтесь!

Контакты Группа ВК Сборник материалов по Cisco, Asterisk, Windows Server, Python и Django, SQL и T-SQL, FreeBSD и LinuxКод обмена баннерами Видео к IT статьям на YoutubeВидео на другие темы Смотреть
Мои друзья: Советы, помощь, инструменты для сис.админа, статическая и динамическая маршрутизация, FreeBSD

© Snakeproject.ru создан в 2013 году.
При копировании материала с сайта - оставьте ссылку.
Весь материал на сайте носит ознакомительный характер,
за его использование другими людьми, автор ответственности не несет.

Рейтинг@Mail.ru
Рейтинг@Mail.ru Яндекс.Метрика





Поддержать автора и проект