Протокол рукопожатия (SSL HP)
Клиент Сервер
Рис. 4.14. Протокол рукопожатия в SSL
Шаг 1. Клиент запрашивает установление соединения, посылая стартовое сообщение (Client Hello), которое содержит: желаемый номер версии протокола;
информацию о времени (текущее время и дата по системному таймеру в стандартном 32-битовом формате, принятом в UNIX- подобных ОС);
идентификатор сеанса (опционально): если он не специфицирован, сервер будет пытаться восстановить предыдущие сеансы либо вернет сообщение об ошибке;
пакет параметров шифрования - список криптографических опций, поддерживаемых клиентом: режимы аутентификации, ме-
4. Криптографические протоколы в олектротюй коммерции и в документообороте 243
тоды обмена ключами, алгоритмы шифрования, генерации и проверки MAC);
методы сжатия, поддерживаемые клиентом;
случайную величину.
Шаг 2. Сервер оценивает параметры, присланные в начальном сообщении клиента, и направляет ему свое начальное сообщение (Server Hello), включающее следующие параметры, выбранные сер-вером для использования в сеансе протокола SSL:
номер версии;
информацию о времени (текущее время и дата по системному таймеру в стандартном 32-битовом формате, принятом в UNIX- подобных ОС);
идентификатор сеанса;
пакет параметров шифрования; метод сжатия;
случайную величину.
После начального сообщения сервер посылает следующие со-общения:
сертификат сервера Certificate (если в протоколе требуется ау-тентификация сервера);
сообщение сервера об обмене ключами Server Key Exchange
(если сертификат недоступен или сертификат содержит только ключ подписи);
запрос сертификата Certificate Request (если в протоколе требу-ется аутентификация клиента).
Наконец, сервер посылает сообщение о завершении серии на-чальных сообщений Server Hello Done и ожидает ответ клиента.
Шаг 5.
Клиент посылает следующие сообщения:если сервер посылал запрос сертификата, клиент должен послать ему в ответ либо сертификат Certificate, либо сообщение об от-сутствии сертификата;
если сервер посылал сообщение сервера об обмене ключами, клиент посылает сообщение клиента об обмене ключами Client Key Exchange, основываясь на асимметричном алгоритме, опре-деленном в начальных сообщениях протокола;
если клиент посылал сертификат, клиент проверяет сертификат сервера и посылает сообщение о проверке сертификата Certifi-cate Verify, содержащее результат проверки.
Затем клиент посылает финальное сообщение Finished, свиде-тельствующее о завершении согласовательной части протокола. Клиент также посылает сообщение об изменении спецификации шифра Change Cipher Specs, чтобы сгенерировать разделяемые секреты. Здесь необходимо заметить, что эта фаза не контролируется протоколом рукопожатия - она управляется протоколом измене-ния спецификации шифра.
Шаг 4. Сервер посылает ответное финальное сообщение Finished, показывающее, что согласовательная часть протокола завер-шилась. Затем он отправляет сообщение об изменении спецификации шифра Change Cipher Specs.
Шаг 5. Наконец, партнеры по сеансу связи каждый по отдельности генерируют ключ шифрования, из которого они затем генерируют ключи, которые будут использовать для шифрования сеанса связи. Протокол рукопожатия изменяет состояние протокола SSL на состоя-ние соединения. Теперь все данные, поступающие с прикладного уров-ня, передаются как специальные сообщения другой стороне.
Как видим, запуск сеанса протокола SSL связан со значительными дополнительными расходами по сравнению с обычным сеансом протокола HTTP. Протокол может избегать части этих накладных расходов, если позволить клиенту и серверу сохранять информацию о сеансовых ключах и возобновлять сеанс протокола без согласования ключей и аутентификации его участников.
Во время выполнения протокола рукопожатия оба партнера по протоколу сгенерировали мастер-ключ.
Из этого ключа они генери-руют другие сеансовые ключи, которые используются для симмет-ричного шифрования данных, передаваемых в текущем сеансе, и для создания кодов аутентификации сообщений. Первое сообщение, за-шифрованное таким образом, является финальным сообщением сер-вера. Если клиент может интерпретировать финальное сообщение, это означает следующее:
Протокол обеспечивает конфиденциальность, поскольку сооб-щение зашифровано при помощи симметричного блочного шифра (например, DES или RC4).
Протоколом гарантирована целостность сообщения, поскольку оно содержит код аутентификации (MAC) самого сообщения и ключевого материала, выведенного из мастер-ключа.
Сервер прошел аутентификацию, так как он оказался способен вычислить мастер-ключ из начального ключевого материала. Так как сообщение было отправлено, используя открытый ключ сервера, оно может быть расшифровано только самим сервером, ис-пользуя соответствующий секретный ключ. Заметим, что при этом предполагается, что обеспечена целостность сертификата открытого ключа сервера.