Как работает SSL рукопожатие / протокол, если у клиента уже есть сертификат сервера?

Question

Мой опыт работы с протоколом SSL / TLS и библиотекой OpenSSL очень ограничен. По сути, я начал узнавать об этом на этой неделе, но я горжусь тем количеством знаний, которые я узнал до сих пор.

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

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

1. Клиент отправляет приветственное сообщение
2. Сервер отвечает своим собственным приветственным сообщением
3. Сервер отправляет сертификат
4. Клиент проверяет сертификат сервера
5. Сервер отправляет сообщение о том, что согласование завершено

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

Я пошел и посмотрел на API OpenSSL, чтобы провести некоторое исследование, и он также оставил в прошлом вопросы. Метод API:

int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type);

при инициализации / настройке всех моих структур OpenSSL я подумал, что это будет файл сертификата сервера, если он уже существует. Но я провел дальнейшие исследования, и его можно использовать как для клиентских, так и для серверных приложений. Так что в случае, когда я являюсь клиентом и у меня нет сертификата сервера, я бы просто отказался от использования вышеуказанного метода API, прежде чем вызывать API SSL_connect () для подтверждения SSL? Полагаю, если бы это было так, я бы как-то использовал API-интерфейсы OpenSSL для сохранения сертификата сервера?

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

Answer 1

Похоже, вы связываете кэширование сертификата («клиент уже имеет сертификат сервера») с кэшированием состояния соединения («избегание генерации ключа при асимметричном рукопожатии»).

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

Однако я не знаю, позволяет ли OpenSSL API (или протокол SSL в этом отношении)вы предполагаете, что у вас уже есть сертификат сервера и пропустите эту часть рукопожатия.Как вы уже поняли, SSL_CTX_use_certificate_file () - это то, что вы вызываете на клиенте для идентификации client сертификата.И это то, что веб-сервер будет вызывать для идентификации своего собственного сертификата сервера.Это не для идентификации сертификата сервера на клиенте или наоборот.

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

[обновление возобновляемых сеансов]

В разделе 7.3 RFC 5246 содержится обзор рукопожатия SSL, включая случай, когда вы возобновляете сеанс.Возобновление сеанса означает, что вы можете пропустить обмен и проверку сертификатов и перейти прямо в зашифрованный сеанс, начиная с сообщения ChangeCipherSpec для согласования секретного ключа.

Кстати, я не думаю, что возобновление сеансов SSL является обычным явлением.на практике.Рукопожатие не , что медленно, и сохранение состояния раздражает.Насколько мне известно, веб-браузеры и серверы обычно не используют эту функцию;они просто делают полное рукопожатие на каждом соединении SSL.