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

Я столкнулся со случаем, когда клиент требует, чтобы я реализовал «взаимную аутентификацию» путем обмена общедоступными сертификатами x509 друг друга. Это слышно?

Я считаю, что это все еще называется взаимной аутентификацией.

Как правило, взаимная аутентификация на основе сертификатов относится к одной из двух моделей. Первая — это корпоративная модель с иерархией ЦС, и ЦС организации подписывает как клиентский, так и серверный сертификат.

Вторая модель — это клиенты, использующие самозаверяющие сертификаты в том, что называется Origin. Привязанные сертификаты. Он называется Origin Bound, потому что каждый сайт (источник), которому нужен сертификат, получает его от клиента. Сертификаты, привязанные к источнику, являются основой протокола привязки токена IETF.

Мне не ясно, имеет ли привязка токена те же свойства безопасности, что и сертификаты, привязанные к источнику. Видите ли, мы можем использовать сертификаты, привязанные к источнику, чтобы предотвратить атаки «человек посередине», сделав аутентификацию частью настройки канала. Привязка токена отделяет привязку и перемещает ее вверх по стеку. Я считаю, что это позволяет MitM выступать в качестве посредника.

Сертификаты предприятия

В корпоративной модели вот что вы делаете с OpenSSL.

На сервере выполните следующее. Сервер будет обрабатывать проверку сертификата клиента:

• Позвоните SSL_CTX_set_verify с помощью SSL_VERIFY_PEER и SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
• Вызовите CTX_set_client_CA_list, чтобы установить список ЦС издателя, который будет принимать сервер. Это приводит к отправке соответствующего сообщения SSL/TLS клиенту с запросом сертификата. Это только отправляет список имен клиенту; им все еще нужно доверять на сервере
• Позвоните SSL_CTX_load_verify_locations с эмитентами, которых принимает сервер. Это добавляет доверия на стороне сервера.

На клиенте выполните следующее:

• Вызовите SSL_CTX_use_certificate_file, чтобы загрузить сертификат клиента
• Звоните SSL_CTX_use_certificate_chain_file по мере необходимости
• Позвоните SSL_CTX_use_PrivateKey, чтобы загрузить закрытый ключ

Привязанные сертификаты происхождения

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

На сервере выполните следующее. Сервер не вызывает SSL_CTX_load_verify_locations или CTX_set_client_CA_list, потому что это самозаверяющий сертификат.

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

На клиенте выполните следующее. Это то же самое, что и корпоративная модель.

• Вызовите SSL_CTX_use_certificate_file, чтобы загрузить сертификат клиента
• Звоните SSL_CTX_use_certificate_chain_file по мере необходимости
• Позвоните SSL_CTX_use_PrivateKey, чтобы загрузить закрытый ключ

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

Атака в этой модели — 500-фунтовая горилла в комнате — это злоумышленник, выдающий себя за пользователя, используя то же отличительное имя и серийный номер, потому что отсутствует центр регистрации (RA). Вам потребуются некоторые меры, чтобы гарантировать, что вас не обманут, например, отправка электронного письма пользователю, чтобы подтвердить, что ожидаются изменения его открытого ключа.

Атака означает, что когда вы регистрируете пользователя, вам нужны три или четыре вещи:

• Уникальная пара {Отличительное имя, серийный номер
• Открытый ключ (часть сертификата X509)
• Адрес электронной почты для подтверждения/восстановления

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

Если взять все вместе, то действительно имеет значение адрес электронной почты и различные открытые ключи/идентификаторы, связанные с адресом электронной почты. Удостоверения хранятся в сертификате X509 с уникальной парой {Отличительное имя, серийный номер. Вы, вероятно, хотите, чтобы они были уникальными для целей аудита, но, вероятно, между устройствами будет происходить копирование/вставка.

Я изо всех сил пытаюсь найти какую-либо документацию или информацию об этом с помощью openssl.

Вероятно, у вас возникли проблемы с поиском информации, потому что это проблема более высокого уровня, архитектуры безопасности и дизайна. Чтобы помочь с некоторыми ссылками, начните с чтения Сертификаты, привязанные к происхождению: новый подход к надежной аутентификации клиентов в Интернете. Также посетите Engineering Security Питера Гутмана и Инженерия безопасности.

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

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

Традиционный метод сертификата клиента использует ЦС и цифровые подписи для проверки подлинности сертификата.

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

Вот пример в Node.JS:

const https = require('https');
const fs = require('fs');

const options = {
    key: fs.readFileSync('/tmp/server.key'),
    cert: fs.readFileSync('/tmp/server.crt'),
    requestCert: true,
    rejectUnauthorized: false
};

https.createServer(options, (req, res) => {
    // We use snake oil certificates and no CA, so we will have an unauthorized cert.
    console.log(req.socket.authorized);
    var cert = req.connection.getPeerCertificate();
    // Here's the cert fingerprint, validate that it's the one you expected
    console.log(cert.fingerprint);

    res.writeHead(200);
    res.end('hello world\n');
}).listen(8000);

Ruby-скрипт для генерации сертификатов и ключей:

require "openssl"

keypair = OpenSSL::PKey::RSA.new(2048)
cert = OpenSSL::X509::Certificate.new
cert.not_before = Time.now
cert.subject = OpenSSL::X509::Name.new([
    ["C", "NO"],
    ["ST", "Oslo"],
    ["L", "Oslo"],
    ["CN", "Root CA"]
                                               ])
cert.issuer = cert.subject
cert.not_after = Time.now + 1000000000 # 40 or so years
cert.public_key = keypair.public_key
cert.sign(keypair, OpenSSL::Digest::SHA256.new)

File.open("/tmp/client.key", "w+") do |f|
  f << keypair.to_pem
end

File.open("/tmp/client.crt", "w+") do |f|
  f << cert.to_pem
end


snakeoil_keypair = OpenSSL::PKey::RSA.new(2048)
snakeoil_cert = OpenSSL::X509::Certificate.new
snakeoil_cert.not_before = Time.now
snakeoil_cert.subject = OpenSSL::X509::Name.new([
    ["C", "NO"],
    ["ST", "Oslo"],
    ["L", "Oslo"],
    ["CN", "Root CA"]
                                               ])
snakeoil_cert.issuer = snakeoil_cert.subject
snakeoil_cert.not_after = Time.now + 1000000000 # 40 or so years
snakeoil_cert.public_key = snakeoil_keypair.public_key
snakeoil_cert.sign(snakeoil_keypair, OpenSSL::Digest::SHA256.new)

File.open("/tmp/server.key", "w+") do |f|
  f << snakeoil_keypair.to_pem
end

File.open("/tmp/server.crt", "w+") do |f|
  f << snakeoil_cert.to_pem
end

Тест с завитком:

curl --insecure --cert /tmp/client.crt --key /tmp/client.key https://localhost:8000

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

Взаимная аутентификация при рукопожатии TLS (или SSL) требует обмена сертификатами обоих узлов.

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

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

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

1. Клиент предлагает в рукопожатии TLS подходящий шифр, требующий проверки подлинности сертификата.
2. Сервер выбирает один из клиентских шифров на основе его конфигурации шифра.
3. Сервер имеет в своем хранилище сертификатов как минимум клиентский корневой ЦС (возможно, также промежуточный клиентский ЦС)
4. Клиенту также необходим корневой ЦС сервера (и, возможно, промежуточный ЦС).

Чтобы выполнить первое условие, список шифров openssl клиента должен включать, например, аутентификацию с использованием шифров на основе RSA, таких как RSA-AES128-SHA256. Вы можете увидеть список клиентских шифров, используя wireshark, просмотрев сообщение client hello. Чтобы определить (или ограничить) количество шифров, вы можете использовать команду openssl ciphers и поиграть со строкой шифра.

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

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