Безопасная аутентификация между клиентом и сервером без ввода логина и пароля / Хабр

Введение:

Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».

Не я первый с этим столкнулся и мир давно уже использует для таких вещей

Поскольку на моём сервере используется nginx, то был установлен модуль SSLГугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.

Внимание! В статье для примера используются самоподписанные сертификаты!

Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:

cd /path/to/nginx/config/
mkdir ssl && cd ssl

Что такое ssl-сертификат?

SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.

Компаниям и организациям необходимо добавлять SSL-сертификаты на веб-сайты для защиты онлайн-транзакций и обеспечения конфиденциальности и безопасности клиентских данных.

SSL обеспечивает безопасность интернет-соединений и не позволяет злоумышленникам считывать или изменять информацию, передаваемую между двумя системами. Если в адресной строке рядом с веб-адресом отображается значок замка, значит этот веб-сайт защищен с помощью SSL.

С момента создания протокола SSL около 25 лет назад, он был доступен в нескольких версиях. При использовании каждой из этих версий в определенный момент возникали проблемы безопасности. Затем появилась обновленная переименованная версия протокола – TLS (Transport Layer Security), которая используется до сих пор. Однако аббревиатура SSL прижилась, поэтому новая версия протокола по-прежнему часто называется старым именем.

Аутентификация на основе общего секретного ключа с использованием hmac

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

HMAC (сокращение от англ. hash-based message authentication code, хеш-код идентификации сообщений). То есть это механизм, который использует криптографические хеш-функции в сочетании с секретным ключом.

Последовательность аутентификации протокола выглядит следующим образом:

Nк, Nс — 128 битное число, выбранное случайным образом клиентом и сервером по отдельности;К, С — идентификаторы клиента и сервера (например, IP адрес); HMAC — хэш код идентификации сообщения;Ks — общий секретный ключ.

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

На втором шаге сервер отправляет клиенту случайное число Nс, а также хэш HMAC, образованный путем хэширования значений Nк, Nс, К, С и Кs при помощи HMAC-функции. Т.к. клиент знает Nк, Nс, К, С и Кs, то он может сформировать свой хэш HMAC, и сравнить его с пришедшим от сервера.

На третьем шаге пришла очередь клиента подтвердить свою «личность». Процесс осуществляется по аналогии со вторым шагом.

Что происходит по истечении срока действия ssl-сертификата?

Срок действия SSL-сертификатов истекает, он не длится вечно. Центр сертификации / Форум браузеров, который де-факто выступает в качестве регулирующего органа для индустрии SSL, заявляет, что срок действия SSL-сертификатов не должен превышать 27 месяцев.

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

Раньше SSL-сертификаты могли выдаваться на срок до пяти лет, который впоследствии был сокращен до трех лет, а в последнее время до двух лет плюс возможность использовать дополнительные три месяца. В 2020 году Google, Apple и Mozilla объявили, что будут применять годовые SSL-сертификаты, несмотря на то, что это предложение было отклонено Центрами сертификации / Форумом браузеров.

Когда срок действия SSL-сертификата истекает, соответствующий сайт становится недоступным. Когда пользователь открывает веб-сайт в браузере, в течение нескольких миллисекунд проверяется действительность SSL-сертификата (в рамках подтверждения SSL-соединения).

У пользователей есть возможность продолжить, однако не рекомендуется делать это, учитывая связанные риски кибербезопасности, в том числе вероятность столкнуться с вредоносными программами. Это существенно влияет на показатель отказов при посещении веб-сайта, поскольку пользователи быстро покидают его.

Осведомленность о сроке истечения SSL-сертификатов является проблемой для крупных предприятий. В то время как малые и средние предприятия имеют один или несколько SSL-сертификатов, крупные предприятия, работающие на различных рынках и имеющие множество веб-сайтов и сетей, имеют также множество SSL-сертификатов.

Поэтому причиной того, что компания допустила истечение срока действия своего SSL-сертификата, обычно является недосмотр, а не отсутствие компетентности. Лучший способ для крупных компаний поддерживать осведомленность об истечении срока действия SSL-сертификатов – использовать платформу управления сертификатами.

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

Если срок действия сертификата истечет, сертификат станет недействительным, и выполнять безопасные транзакции на веб-сайте станет невозможно. Центр сертификации предложит обновить SSL-сертификат до истечения срока его действия.

Все центры сертификации и службы SSL, используемые для получения SSL-сертификатов, отправляют уведомления об истечении срока действия сертификата с заданной периодичностью, обычно начиная с 90 дней до окончания срока действия сертификата. Постарайтесь, чтобы эти уведомления отправлялись на несколько адресов электронной почты, а не одному человеку, который к моменту отправки уведомления может покинуть компанию или перейти на другую должность. Убедитесь, что соответствующие сотрудники компании включены в список рассылки и своевременно получат уведомление.

1 Подготовка CA

Создадим конфигnano ca.config

со следующим содержимым:

[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов

database = $dir/index.txt # Файл с базой данных подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер сертификата (в шестнадцатеричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA

default_days = 365 # Срок действия подписываемого сертификата
default_crl_days = 7 # Срок действия CRL
default_md = md5 # Алгоритм подписи

policy = policy_anything # Название секции с описанием политики в отношении данных сертификата

[ policy_anything ]
countryName = optional # Поля optional - не обязательны, supplied - обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле

2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)

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

3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

openssl ca -config ca.config -in client01.csr -out client01.crt -batch

В результате выполнения команды появится файл клиентского сертификата client01.crt.

Для создания следующих сертификатов нужно повторять эти два шага.

4. Создание сертификата в формате PKCS#12 для браузера клиента

Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.

Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.

openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3

Keystore & truststore

Говоря о JKS, стоит отметить, что данные файлы могут использоваться как KeyStore так и TrustStore. Это два различных типа хранилищ, которые находятся в JKS файлах. Одно из них (KeyStore) содержит более чувствительную информацию типа приватного ключа, и поэтому требует пароля для доступа к этой информации.

Но так же эти сертификаты идут в поставке Java в файле cacerts, который по умолчанию расположен в директории java.homelibsecurity и имеет пароль по умолчанию changeit.

Данная информация может быть полезна в тех случаях, когда установка JDK/JRE осуществляется в компании централизовано из одного источника, и имеется возможность добавления туда своих доверенных сертификатов компании для prod/uat окружения.

Ниже приведена таблица с некоторыми различиями KeyStore & TrustStore.

Wildcard-сертификаты

Wildcard-сертификаты (сертификаты с подстановочными символами) позволяют защитить базовый домен и неограниченное количество поддоменов с помощью одного сертификата. Если имеется несколько поддоменов, которые нужно защитить, приобретение Wildcard-сертификата будет намного дешевле, чем приобретение отдельных SSL-сертификатов для каждого поддомена.

Wildcard-сертификаты содержат звездочку (*) как часть общего имени. Звездочка указывается вместо любого допустимого поддомена в составе одного базового домена. Например, один Wildcard-сертификат для веб-сайта можно использовать для защиты следующих страниц:

Алгоритм системы аутентификации

Далее все этапы установления соединения были описаны с помощью блок-схем.

Алгоритм системы аутентификации со стороны клиента выглядит следующим образом:

Со стороны сервера:

После успешной аутентификации можно передавать зашифрованный трафик. Предполагается, что трафик будит шифроваться с помощью алгоритма AES, используя секретный ключ Ks. Почему AES? Потому что это наилучший на сегодняшний день симметричный алгоритм шифрования. Подробнее о нем можно узнать в интернете.

Анализ системы на защищенность от атак

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

Аутентификация с помощью шифрования открытого ключа

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

Nк, Nс — 128 битное число, выбранное случайным образом клиентом и сервером по отдельности;К, С — идентификаторы клиента и сервера (например, IP адрес); Ks — общий секретный ключ;Ec, Eк — открытые ключи сервера и клиента соответственно, которые передаются в виде сертификатов.

Сначала клиент запрашивает открытый ключ сервера (Ес) у центра сертификации. Затем он шифрует с помощью него случайно выбранное число и свой идентификатор (шаг 3). Только настоящий сервер может расшифровать это сообщение. Поэтому сервер, получая данное сообщение, расшифровывает его, и шифрует с помощью открытого ключа клиента (который он получает у центра сертификации) случайное число клиента, свое случайное число, и общий секретный ключ (шаг 6).

Далее, если клиент является тем, за кого себя выдает, расшифровывает сообщение сервера, узнает общий секретный ключ, и для подтверждения, что он смог расшифровать сообщение сервера, отсылает серверу случайно число Nc, зашифровав его общим секретным ключом (шаг 7).

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

Дополнительная защита обеспечивается сменой общего секретного ключа (Ks) через случайный промежуток времени (Tk). Подробнее об этом написано в разделе «Анализ системы на защищенность от атак»

Включение аутентификации сертификата в ocserv демоне

Отредактируйте файл конфигурации ocserv.

sudo nano /etc/ocserv/ocserv.conf

Чтобы включить аутентификацию по сертификату, раскомментируйте следующую строку.

auth = "certificate"

Если следующая строка также незакоментирована, это означает, что пользователь также должен ввести имя пользователя и пароль.

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

auth = "plain[passwd=/etc/ocserv/ocpasswd]"

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

enable-auth = "plain[passwd=/etc/ocserv/ocpasswd]"

Теперь найдите следующую строку.

ca-cert = /etc/ssl/certs/ssl-cert-snakeoil.pem

Для проверки сертификата клиента нам необходимо использовать наш собственный сертификат ЦС, поэтому измените эту строку на

ca-cert = /etc/ocserv/ssl/ca-cert.pem

Затем найдите следующую строку.

Запрос подписи сертификата

Чтобы секретные ключи конечных пользователей были секретными, пользователи могут генерировать запрос подписи сертификата (CSR) со своими личными ключами, а затем отправлять запросы сертификатов администратору, который затем выдает клиентские сертификаты пользователям.

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

Затем создайте CSR с помощью следующей команды.

Файл request.pem подписывается закрытым ключом пользователя.

certtool --generate-request --load-privkey client-privkey.pem --template client-cert.cfg --outfile request.pem

Затем пользователь отправляет файл request.pem и client-cert.cfg администратору, который выполняет следующую команду для создания сертификата клиента.

sudo certtool --generate-certificate --load-ca-certificate ca-cert.pem --load-ca-privkey ca-privkey.pem --load-request request.pem --template client-cert.cfg --outfile client-cert.pem

После этого администратор отправляет пользователю сертификат сертификата cert.pem.

Зачем нужен ssl-сертификат

SSL-сертификаты сайтов требуются для обеспечения безопасности данных пользователей, подтверждения прав собственности на сайт, предотвращения создание поддельной версии сайта злоумышленниками и обеспечения доверия со стороны пользователей.

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

Использование аутентификации по сертификату на ubuntu

Используйте команду scp для загрузки файла client.p12 на рабочий стол Ubuntu.

Использование аутентификации по сертификату на устройстве ios

Пользователи iOS могут использовать приложение Cisco AnyConnect.

Чтобы импортировать сертификат клиента в приложение AnyConnect, вы можете сначала отправить файл PKCS # 12 на свой адрес электронной почты в приложении. Затем откройте приложение mail на iOS. Нажмите на приложение несколько секунд и поделитесь им с AnyConnect.

Затем введите PIN-код для импорта файла.

Использование проверки подлинности сертификата в windows и macos

Загрузите клиент GUI OpenConnect для Window или MacOS со страницы OpenConnect GUI Github.

Затем создайте новый профиль подключения VPN и импортируйте файл PKCS # 12 в поле сертификата пользователя.

Нажмите кнопку «Сохранить».

Вам нужно будет ввести PIN-код, чтобы разблокировать закрытый ключ.

После импорта вам больше не нужно вводить имя пользователя и пароль.

Использованное по

Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)

nginx 0.9.3

OpenSSL 0.9.8o 01 Jun 2021

Как обеспечить безопасность онлайн-сеанса

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

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

Ознакомьтесь с политикой конфиденциальности веб-сайта. Это позволяет понять, как будут использоваться ваши данные. Законопослушные компании обычно прозрачно описывают сбор и действия с данными.

Обратите внимание на сигналы и индикаторы, вызывающие доверие к веб-сайту.
Наряду с SSL-сертификатами, это могут быть логотипы или значки, показывающие репутацию и соответствие веб-сайта определенным стандартам безопасности. Другие признаки, по которым можно оценить сайт, включают проверку физического адреса и номера телефона, ознакомление с политикой возврата товаров и средств, проверку правдоподобности цен – ведь бесплатный сыр может оказаться в мышеловке.

Как получить ssl-сертификат

SSL-сертификат можно получить непосредственно в центре сертификации. Центры сертификации, иногда также называемые сертифицирующими организациями, ежегодно выдают миллионы SSL-сертификатов. Они играют важную роль в работе интернета и обеспечивают прозрачное и надежное взаимодействие в сети.

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

Получение SSL-сертификата включает следующие шаги:

После получения сертификата его необходимо настроить на вашем веб-хосте или серверах, если вы обеспечиваете хостинг веб-сайта самостоятельно.

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

Как узнать, есть ли у сайта ssl-сертификат

Самый простой способ узнать, есть ли у сайта SSL-сертификат – обратить внимание на следующие элементы в адресной строке браузера:

Конфиг nginx

listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;

keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;

Можно ли использовать ssl-сертификат на нескольких серверах?

Один SSL-сертификат можно использовать для нескольких доменов на одном сервере. В зависимости от поставщика, можно также использовать один SSL-сертификат на нескольких серверах. Это позволяют мультидоменные SSL-сертификаты, описанные выше.

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

Мультидоменные SSL-сертификаты также называются SAN-сертификатами. SAN означает альтернативное имя субъекта. Каждый мультидоменный сертификат имеет дополнительные поля (например, альтернативные имена субъектов), которые можно использовать для перечисления дополнительных доменов, чтобы на них распространялся один сертификат.

Сертификаты унифицированных коммуникаций (UCC) и Wildcard-сертификаты также можно применять на нескольких доменах и, в последнем случае, на неограниченном количестве поддоменов.

Мультидоменные сертификаты (mdc)

Мультидоменные сертификаты можно использовать для защиты нескольких доменных и поддоменных имен, включая сочетания полностью уникальных доменов и поддоменов с разными доменами верхнего уровня (TLD), за исключением локальных / внутренних доменов.

Например:

Настройка собственного центра ca(центра сертификации)

Мы будем использовать аутентификацию по сертификату, но Let’s Encrypt не выдаёт сертификат клиента, поэтому нам нужно создать собственный CA.

Вы можете открыть opensll для выполнения задания, но ocserv рекомендует GnuTLS, поэтому я покажу вам, как использовать GnuTLS. Установите пакет gnutls-bin.

sudo apt install gnutls-bin

Создайте подкаталог в /etc/ocserv/ для хранения секретных ключей и сертификатов.

sudo mkdir /etc/ocserv/ssl/

Измените рабочий каталог.

cd /etc/ocserv/ssl/

Создайте закрытый ключ для CA с помощью команды certtool, которая предоставляется пакетом gnutls-bin.

По умолчанию он генерирует 3072-разрядный RSA-ключ, которого достаточно.

sudo certtool --generate-privkey --outfile ca-privkey.pem

Прежде чем создавать сертификат CA, давайте создадим файл шаблона сертификата CA.

Формат файла шаблона можно найти в руководстве certtool (man certtool).

sudo nano ca-cert.cfg

Добавьте в файл следующие строки.

Замените параметры соответствующими значениями.

# X.509 Certificate options

# The organization of the subject.
organization = "Example Org"

# The common name of the certificate owner.
cn = "Example CA"

# The serial number of the certificate.
serial = 001

# In how many days, counting from today, this certificate will expire. Use -1 if there is no expiration date.
expiration_days = -1

# Whether this is a CA certificate or not
ca

# Whether this certificate will be used to sign data
signing_key

# Whether this key will be used to sign other certificates.
cert_signing_key

# Whether this key will be used to sign CRLs.
crl_signing_key

Сохраните и закройте файл. Теперь создайте сертификат CA, используя конфигурации из файла шаблона.

sudo certtool --generate-self-signed --load-privkey ca-privkey.pem --template ca-cert.cfg --outfile ca-cert.pem

Теперь у нас есть файл сертификата CA (ca-cert.pem).

Подключение ssl в grpc / rsocket

Если говорить о двунаправленном обмене бинарными данными, современных тенденциях к написанию реактивных приложений, стоит отметить gRPC и RSocket для создания подобных приложений. Но поскольку в основании этих протоколов можно использовать Netty как транспорт, логика конфигурирования останется. Поэтому я не буду уделять этому много внимания.

Подключение ssl в spring boot для restcontroller

Но в мире Java разработки Spring стал де факто стандартом для DI. А вместе с внедрением зависимости люди используют и другие технологии, которые удобно собрать в одном Spring Boot приложении, не расходуя множество времени на конфигурирование всего зоопарка технологий.

Конечно же, это приводит к избыточности зависимостей и к увеличению времени загрузки, но упрощает разработку. Куда проще написать аннотацию RestController, чем самому разбираться с тем, как корректно хендлить запросы через сервлеты. А для того, чтобы перенаправить всё взаимодействие через сервлеты в защищённый канал с использованием сертификатов, в Spring Boot есть два пути проcтой и более сложный для кастомных решений.В первом случае достаточно воспользоваться набором пропертей

server.ssl.key-store-type=JKS
server.ssl.key-store=classpath:cert.jks
server.ssl.key-store-password=changeit
server.ssl.key-alias=key
trust.store=classpath:cert.jks
trust.store.password=changeit

И все будет сделано за вас. Либо, если требуется более кастомная конфигурация, поднятие коннекторов на разных портах с нестандартными настройками и так далее, тогда путь лежит в сторону использования интерфейса WebServerFactoryCustomizer, имплементации которого существуют для всех основных контейнеров будь то Jetty, Tomcat или Undertow.

Поскольку это функциональный интерфейс, его довольно просто можно описать через lambda c параметром типа Connector. Для него мы можем выставить флаг setSecure(true), затем заполнить необходимые параметры для ProtocolHandler-а, выставив ему пути до jks c keystore и trustStore и соответствующие пароли к ним. Например, для tomcat код будет выглядеть подобным образом:

Подключение ssl к nettyserver

При создании нового проекта, подразумевающего взаимодействие клиента и сервера бинарными данными(protobuf) через защищенные вебсокеты (wss), возник вопрос подключения SSL в netty сервер. Как оказалось, это не представляет особых проблем, достаточно в билдере сетевого интерфейса добавить метод .withSslContext(), в который необходимо передать созданный контекст.

Подключение клиентов к серверу без необходимости

Что может произойти, если кто-то получит клиент нашего анализатора?

С одной стороны, т.к. сервер не передает никакую важную информацию клиенту (только команды), а клиент в свою очередь никак не может получить доступ к важным данным сервера и только отсылает трафик, это не вызовет никаких серьезных неудобств.

Единственное, что может причинить неудобства, БД сервера может неприлично увеличиться, но это забота сервера и администратора отключать ненужные клиенты от работы сети (т.к. для заполнения БД требуется достаточно много времени).

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

Здесь можно просто напросто банить на время таких клиентов. Также клиент не может инициализировать обновление секретного ключа. Единственный, кто знает время действия общего секретного ключа — это сам сервер. И только он может посылать запрос на обновление общего секретного ключа.

Полезные ссылки

Надеюсь, был кому-то полезен.

P.S. Этот пост был моей первой публикацией 16 января 2021 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).

Получение злоумышленником секретного ключа клиента и трафика этого клиента

В данной ситуации предполагается, что злоумышленник заполучил секретный ключ и трафик клиента.

m — сетевой пакет (сообщение), который шифруется секретным ключом.

Как говорилось ранее, установление общего секретного ключа между агентом и сервером в доверенной зоне происходит с помощью алгоритма Диффи-Хеллмана. В отличие от стандартного Диффи-Хеллмана, в моем случае предполагается смена общего ключа (Ks) через случайный промежуток времени, который лежит на интервале времени (Tmin, Tmax), где Tmin и Tmax устанавливаются в настройках серверной части приложения.

Данный способ позволяет частично обеспечить forward secrecy (секретность будущих сообщений) и backward secrecy (секретность прошлых сообщений). То есть если допустить, что находящийся внутри предприятия злоумышленник имеет записанный ранее трафик, и при этом ему удалось получить текущий общий секретный ключ Ks(i), он сможет расшифровать только такой трафик, который был передан на интервале (Tmin(i), Tmax(i)), где i — текущий номер сгенерированного общего секретного ключа.

Предпосылки

Чтобы следовать этому руководству, предполагается, что вы уже настроили сервер OpenConnect VPN с сертификатом сервера Let’s Encrypt TLS.

Мы создадим наш собственный центр сертификации (Certificate Authority) для подписывания сертификата клиента.

Демон ocserv должен продолжать использовать сертификат сервера TLS, выпущенный Let’s Encrypt, поэтому клиентское программное обеспечение не будет отображать предупреждение о безопасности.

Сертификаты унифицированных коммуникаций (ucc)

Сертификаты унифицированных коммуникаций (UCC) также считаются мультидоменными SSL-сертификатами. Сертификаты унифицированных коммуникаций изначально были разработаны для защиты серверов Microsoft Exchange и Live Communications. Сегодня любой владелец веб-сайта может использовать эти сертификаты, чтобы обеспечить защиту нескольких доменных имен с помощью одного сертификата.

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

Важно различать типы SSL-сертификатов, чтобы получить правильный тип сертификата для веб-сайта.

Сертификаты, подтверждающие организацию (ov ssl)

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

SSL-сертификаты, подтверждающие организацию, обычно являются вторыми по стоимости (после SSL-сертификатов с расширенной проверкой). Их основная цель – зашифровать конфиденциальные данные пользователей при транзакциях. Коммерческие или общедоступные веб-сайты должны устанавливать сертификаты, подтверждающие организацию, чтобы гарантировать конфиденциальность информации о клиентах.

Создайте файл шаблона сертификата клиента.

sudo nano client-cert.cfg

Добавьте следующие строки в файл. Uid должен быть именем пользователя в файле /etc/ocserv/ocpasswd.

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

Теперь запустите следующую команду для создания закрытого ключа клиента.

sudo certtool --generate-privkey --outfile client-privkey.pem

Тестирование tls/ssl

Для того чтобы провести тестирование реализованного безопасного подключения имеется возможность создать keystore программно, используя классы из пакета java.security.* Это даст возможность тестировать различное поведение системы в случае разных ситуаций типа истекших сертификатов, проверки корректной валидации доверенных сертификатов и так далее.

Чтобы грамотно проверить работоспобность придется пройти по всем составным частям jks и воссоздать программно внутри KeyStore пару ключей KeyPair, свой сертификат X509Certificate, цепочку родительских сертификатов, подпись и доверенные корневые сертификаты.

Для упрощения этой задачи можно воспользоваться библиотекой bouncyСastle, которая предоставляет ряд дополнительный возможностей в дополнение к стандартным классам в Java, посвященным криптографии из Java Cryptography Architecture (JCA) и Java Cryptography Extension (JCE).

Типы ssl-сертификатов

Существуют разные типы SSL-сертификатов с разными уровнями проверки. Шесть основных типов:

1. Сертификаты с расширенной проверкой (EV SSL)
2. Сертификаты, подтверждающие организацию (OV SSL)
3. Сертификаты, подтверждающие домен (DV SSL)
4. Wildcard-сертификаты
5. Мультидоменные сертификаты (MDC)
6. Сертификаты унифицированных коммуникаций (UCC)

Уязвимость алгоритма диффи-хеллмана к mitm атакам

Это, пожалуй, главный недостаток данного алгоритма. Если допустить, что злоумышленник выдает себя за сервер клиенту, и за клиент серверу (например, используя ARP-spoofing), то весь трафик будит проходить через злоумышленника.

Защититься от такого рода атак можно только грамотно продумав сетевую архитектуру и правила ИБ предприятия. Например, можно установить ПО по обнаружению ARP-spoofinga и подобных атак.

Формат сертификатов

В рамках работы с сертификатами обычно используется контейнер PKCS 12 для хранения ключей и сертификатов, но в рамках Java, в дополнение широко используется проприетарный формат JKS (Java KeyStore). Для работы с хранилищем JDK поставляется с консольной утилитой keytool.

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

Шаг 2. сертификат сервера

Создадим сертификат для nginx и запрос для него

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

Подпишем сертификат нашей же собственной подписью

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата

openssl rsa -in server.key -out server.nopass.key

Заключение

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

В конце был проведен краткий анализ подверженности спроектированной системы к компьютерным атакам.

P.S. Буду рад комментариям, исправлениям и аргументированной критике.