Лекція №8 Таблица 5. Сообщения протокола Handshake в хронологическом порядке

Висновки

Таблица 5. Сообщения протокола Handshake в хронологическом порядке

Протокол Handshake

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

Протокол начинается с обязательной аутентификации сервера, аутентификация клиента необязательна. Как только совершена аутентификация, стороны переходят в фазу уточнения параметров сеанса, в которой выбирается набор и параметры криптоалгоритмов (Cipher Suite). Таким образом, протокол Handshake определяет весь процесс безопасной передачи данных, что делает его главной мишенью для атак.

В таблице 5 представлен список сообщений протокола Handshake в хронологическом порядке, а рис. 6 иллюстрирует обмен данными при установлении сеанса.

Любое сообщение содержит следующие поля:

· тип (1 байт); указывает один из 10 типов сообщений, содержащихся в таблице 5;

· длина (3 байта); длина сообщения в байтах;

· содержимое (³ 1 байта); параметры.

Сообщение	Тип сообщения (O -опционально, M - обязательно)	Направление передачи (С - сервер, К - клиент)	Описание
HelloRequest	O	C®K	Информирует клиента о начале процедуры Handshake
ClientHello	M	K®C	В этом сообщении содержатся: · версия протокола SSL; · случайное число Client_random; · идентификатор сеанса session_ID; · список cipher suites, доступных клиенту; · список методов сжатия, доступных клиенту
ServerHello	M	C®K	В этом сообщении содержатся: · версия протокола SSL; · случайное число Server_random; · идентификатор сеанса session_ID; · выбранный cipher suite; · выбранный метод сжатия
Certificate	O	C®K K®C	В сообщении содержится сертификат сервера или сертификат клиента (если у клиента он есть и сервер запросил его)
ServerKey Exchange	O	С®К	Сервер отправляет это сообщение только тогда, когда у него нет сертификата или есть только сертификат подписи
CertificateRequest	O	С®К	Сервер запрашивает сертификат клиента
ServerHelloDone	M	С®К	Это сообщение информирует клиента, что передача сообщения ServerHello и последующих сообщений завершена
ClientKey Exchange	M	К®С	Содержит ключ PreMasterSecret, зашифрованный открытым ключом сервера
CertificateVerify	O	К®С	Позволяет однозначно убедиться в подлинности сертификата клиента
Finished	M	С®К К®С	Означает конец процедуры Handshake и начало передачи данных, зашифрованных в соответствии с установленными параметрами; содержит хеш-образы

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

Согласно версии 3 протокола SSL обмен данными при установлении нового сеанса включает четыре этапа:

· определение доступных сторонам cipher suites;

· аутентификация сервера;

· обмен ключами;

· проверка и подтверждение переданных и принятых сообщений.

Определение доступных криптопакетов (cipher suites). Первые сообщения, ClientHello и ServerHello, позволяют согласовать алгоритмы шифрования и сеансовые ключи. Клиент и сервер начинают с выбора версии протокола SSL, которая должна быть одинаковой для обеих сторон (версия 3 или по умолчанию версия 2). Даже если сообщение ClientHello определяет для сеанса версию 3, оно все равно инкапсулировано в сообщении Record в формате, определенном версией 2. Это дает серверу способность ответить даже в том случае, если он не был модернизирован до версии 3.

После передачи сообщения ClientHello клиент ждет прибытия сообщения ServerHello. Это сообщение определяет версию протокола и уникальный идентификатор сеанса, который выбрал сервер. Идентификатор сеанса используется, чтобы возобновить уже установленный сеанс (будет детально рассмотрено далее). Сообщение также содержит случайный номер, server_random. В результате обмена числами client_random и server_random каждая сторона сможет сформировать совместно используемые (разделяемые) с корреспондентом секретные ключи.

Сообщение должно содержать описание cipher suite, выбранного сервером из числа предложенных клиентом. Именно он будет использоваться для обеспечения секретности и аутентичности данных. Если нет возможности определить общий совместимый cipher suite, сервер (или клиент, в зависимости от каждого конкретного случая) генерирует сообщение об ошибке close_notify, как определено в соответствии с аварийным протоколом Alert, а сеанс будет прерван. Следует отметить, что некоторые серверы не посылают сообщение close_notify, азакрывают сеанс TCP без предупреждения.

Важно помнить, что все эти переговоры происходят в открытом виде. Противник может попытаться прервать сообщение ClientHello и подменить его фальсифицированным, определяющим менее стойкие алгоритмы шифрования. Защита от такой атаки может быть осуществлена при помощи сообщения Finished, которое передается в конце процедуры Handshake.

Аутентификация сервера. На второй стадии сервер подтверждает свою подлинность путем передачи сообщения Certificate, включающего в себя:

· сертификат сервера Х.509 версии 3, содержащий открытый ключ предварительно выбранного cipher suite (протокол Alert выдаст ошибку, если сертификат не включен в сообщение);

· количество уровней сертификации (например: сертификат есть только у сервера; сертификаты есть и у клиента, и у сервера) и сертификат центра. Сертификат Х.509 имеет следующий вид:

Certificate = Name_Server || Name_CA || РК_Server || SK_CA {H [Name_Server || Name_CA || РК_Server ]},

где Name_Server ‑ имя сервера;

Name_CA ‑ имя центра, выдавшего сертификат;

РК_Server ‑ открытый ключ сервера;

SK_CA { х } ‑ сообщение х, подписанное закрытым ключом центра;

H [y] ‑ хеш-образ сообщения у.

Если сервер не имеет сертификата, то вместо сообщения Certificate он передает сообщение ServerKeyExchange. Однако серверы, используемые в электронной торговле, заинтересованы в том, чтобы быть аутентифицированными.

Даже если сервер предоставляет сертификат, он должен передать сообщение ServerKeyExchange в следующих случаях.

· Используется алгоритм обмена ключами Fortezza. В этом случае сообщение ServerKeyExchange отправляется без сигнатуры.

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

· Для обмена ключами используется метод Диффи-Хеллмана с одноразовыми параметрами. В этом случае сообщение ServerKeyExchange содержит сертификат подписи для аутентификации параметров, используемых при обмене ключами.

Таким образом, когда используется сертификат подписи, сервер передает два последовательных сообщения: сообщение Certificate, затем сообщение ServerKeyExchange. Сообщение Certificate содержит открытый ключ сервера в сертификате, который подписан закрытым ключом центра. Клиент проверяет сертификат с помощью открытого ключа центра. Сообщение ServerKeyExchange содержит открытые параметры алгоритма, используемого для формирования секретного ключа симметричного шифрования. Сервер подписывает эти параметры с помощью закрытого ключа, который соответствует открытому ключу, восстановленному на первом шаге. После получения второго сообщения клиент убеждается, что открытые параметры алгоритма обмена ключами именно те, которые используются сервером, проверяя сигнатуру при помощи ранее полученного открытого ключа. Это сообщение содержит хеш-образ конкатенации переменных client_random, server_random, а также других параметров сервера. Хеширование осуществляется одним из алгоритмов, MD5 или SHA.

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

Затем сервер посылает сообщение ServerHelloDone, уведомляющее клиента об окончании передачи сервером и его переходе в режим ожидания ответа.

Обмен ключами. Если сервер запрашивает аутентификацию клиента, используя сообщение CertificateRequest, клиент должен ответить включением своего сертификата, если он есть, в сообщении Certificate. Если клиент не может предоставить сертификат, ответ ‑ no_certificate. В общем случае это сообщение является простым предупреждением (warning). Если же сервер требует аутентификации клиента, происходит разрыв соединения. Затем клиент посылает сообщение ClientKeyExchange, которое содержит параметр PreMasterSecret, зашифрованный с помощью открытого ключа сервера или с помощью ключа, включенного в сертификат шифрования, в зависимости от типа сертификата и алгоритма, используемого для обмена ключами.

Рассмотрим содержимое этого сообщения для следующих трех случаев.

· Сертификат сервера является сертификатом подписи, используется алгоритм RSA. Формируется PreMasterSecret, который шифруется открытым ключом сервера или временным ключом, содержащимся в сообщении ServerKeyExchange (как было описано выше).

· Обмен ключами основан на алгоритме Fortezza. Ключ ТЕК (Token Encryption Key) вычисляется на основе параметров, переданных сервером в сообщении ServerKeyExhange. Этот ключ используется для шифрования client key, client write key, PreMasterSecret и векторов инициализации.

· Обмен ключами по алгоритму Диффи-Хеллмана. При помощи сообщений ServerKeyExchange и ClientKeyExchange происходит обмен открытыми параметрами алгоритма, если эти параметры одноразовые, т.е. уже не включены в сертификаты клиента и сервера.

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

Содержание сообщения CertificateVerify будет следующим:

hash { MasterSecret || pad_2 || hash (все_отправленные_сообщения_кроме_этого || MasterSecret || pad_l)},

где hash - MD5 или SHA. Поля pad_l и pad_2 содержат 48 и 40 повторений байтов 0x36 и 0х5С соответственно для случая MD5 и SHA.

Для запуска процесса шифрования данных клиент вызывает протокол ChangeCipherSpec с опциями, выбранными на предыдущих двух стадиях. По завершении приема данных клиент немедленно посылает сообщение Finished. Это сообщение является результатом хеширования всех сообщений Handshake, которые передал клиент, начиная с ClientHello; хеш-функция использует только что согласованные криптографические атрибуты. Цель состоит в том, чтобы предотвращать атаки типа «человек в середине» (man-in-the-middle), проверяя целостность пакетов передаваемых данных. Хеширование осуществляется следующим образом:

hash { MasterSecret || pad_2 || hash (handshake_messages || Sender || MasterSecret || pad_l) },

где hash — MD5 или SHA. Поле handshake_messages содержит переданные сообщения, за исключением ChangeCipherSpec и текущего сообщения. Следует обратить внимание на присутствие поля Sender, которое содержит идентификатор отправителя.

Передав сообщение Finished, клиент начинает шифровать передаваемые данные без ожидания подтверждения.

Обратите внимание, что сообщение ChangeCipherSpec не используется при хешировании, потому что оно не является частью протокола Handshake. Из соображений безопасности предпочтительнее не обрабатывать полученное сообщение Finished, если оно не следует за сообщением ChangeCipherSpec. MasterSecret включен в MAC сообщений CertificateVerify, ChangeCipherSpec и Finished.

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

Передача данных непосредственно после отправки сообщения Finished может открыть брешь в защите. Атакующий может попытаться изменить сообщения ClientHello или ServerHello, чтобы определить использование более слабого алгоритма шифрования, вычислить РгеMasterSecret и отклонить сообщение Finished. Таким образом, атакующий может подменить собой одну или обе стороны. Чтобы защититься от такого типа атак, достаточно задержать передачу данных до момента, пока сообщения Finished не будут получены от обеих сторон.

Установка сеанса. На рис. 7 и 8 показаны диаграммы состояний клиента и сервера в процессе установки сеанса. Система обозначений, применяемая в этих диаграммах, та, которая обычно используется в формальных методах описания протоколов связи. Таким образом, processA!message1 означает, что processA посылает сообщение message1, a processB?Message2 ‑ что processB получил сообщение message2. Процесс SSL имеет два интерфейса ‑ один с приложениями, другой с протоколом TCP; последний представлен на рисунках.

Установка соединения. Установка первого соединения SSL происходит аналогично установке сеанса. Если сеанс SSL уже был установлен, пакеты TCP могут передаваться в обоих направлениях. Таким образом, установка нового соединения заключается в обновлении параметров client_random и server_random в сообщениях ClientHello и ServerHello, при сохранении ранее выбранных алгоритмов шифрования и хеширования. В отличие от процедуры установки сеанса, повторной аутентификации не происходит, а сообщения ClientHello и ServerHello зашифрованы. На рис. 9отражен обмен сообщениями при установке соединения.

Сообщение ClientHello содержит идентификатор сеанса, в рамках которого будет совершено подключение. Если этот идентификатор отсутствует в таблицах сервера, или идентификатор некорректен, или сеанс, к которому он относится, истек, запрос клиента отклоняется, и сервер начинает новую процедуру Handshake для установки нового сеанса.

Клиент и сервер подтверждают соединение, посылая сообщение ChangeCipherSpec от каждой стороны, и заканчивают сокращенную процедуру Handshake сообщением Finished.

Рис. 8.Последовательность установки сеанса на стороне сервера

Рис. 9.Последовательность обмена сообщениями в процессе установки соединения

На рис. 10 показаны функции протоколов SSL.

Рис. 10. Функции протоколов SSL

Обратите внимание, что спецификация протокола SSL не дает четкого определения действий в ситуации смены cipher suite. Точно так же не ясно, может ли в сеансе, предварительно установленном версией SSL 3.0, новое подключение иметь версию 2.0. В любом случае смешение версий может ослабить защиту (из-за слабости версии 2) и поэтому не рекомендовано.

В настоящее время SSL — основной массово используемый протокол защиты данных. Он также применяется в основных платформах защиты информации в Сети, на клиентских и серверных сторонах. Протокол предлагает аутентификацию, конфиденциальность, целостность данных для приложений «точка-точка» (Point-to-point). SSL адаптирован для сложных (более сложных, чем, например, у WAP (Wireless Application Consortium), использующего SSL в приложениях радиосвязи) транзакционных приложений. Использование версий протокола SSL возможно в мобильной связи и смарт-картах.

Модульная архитектура позволяет развивать некоторые части SSL без влияния на структуру в целом. Развитие алгоритмов шифрования открывает перспективу для развития SSL по мере появления новых алгоритмов. Структура SSL также позволяет адаптировать его под особенности национального законодательства.

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

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

Контрольні питання

1. Какое место занимает SSL протокол в иерархии модели OSI?
2. Какие протоколы может защищать SSL протокол?
3. Какие задачи позволяет решать SSL протокол?
4. Как обеспечивается конфиденциальность сообщений в SSL протоколе?
5. Из каких субпротоколов состоит SSL протокол?
6. Сколько этапов присутствует в SSL протоколе при обмене данными?
7. Какие методы обмена ключами поддерживает протокол SSL?
8. Какие используются переменные при создании главного разделяемого клиентом и сервером ключа MasterSecret в начале сеанса SSL соединения?
9. Из каких этапов в версии 3 протокола SSL состоит обмен данными при установлении нового сеанса?

[1] Internet Engineering Task Force — проблемная группа проектирования Интернета, одна из групп IАВ (Internet Activities Board - технический орган, обеспечивающий развитие набора протоколов Интернета (TCP), включает технические группы IRTF и IETF), отвечающая за решение инженерных задач Интернета, выпускает большинство RFC (серия документов IETF, начатая в 1969 году и содержащая описания набора протоколов Интернета и связанную с ними информацию), используемых производителями для внедрения стандартов в архитектуру TCP/IP.