Протокол Handshake работает поверх протокола Record и используется для согласования нижеприведенных параметров сессии.
Идентификатор сессии | - | произвольная последовательность байтов, выработанная сервером для идентификации активной или возобновляемой сессии. |
Сертификат стороны | - | сертификат в формате X.509, формирующийся в соответствии с Р 1323565.1.023. Аутентификация опционально может быть односторонней (аутентификация сервера клиентом, сертификат предоставляет только сервер) или двусторонней (двусторонняя аутентификация сервера и клиента, клиент и сервер обмениваются сертификатами). |
Идентификатор криптонабора | - | идентификатор, определяющий набор алгоритмов и их параметров, использующихся в рамках данной сессии. |
Значение MS (master secret) | - | общее секретное значение длиной 48 байтов, которое вырабатывается сторонами с помощью протокола выработки и подтверждения ключа (см. 6.4). |
Значение флага возобновления | - | флаг, разрешающий/запрещающий повторные соединения в рамках данной сессии. |
Протокол Handshake начинает свою работу с сообщения ClientHello, которое может быть послано клиентом по его собственной инициативе либо в качестве ответа на сообщение сервера HelloRequest.
Схема обмена сообщениями Handshake может быть полной или упрощенной.
Полная схема обмена сообщениями (см. рисунок 3) используется, если клиент в сообщении приветствия ClientHello в качестве идентификатора сессии указал пустую строку, либо в том случае, если сервер не смог найти в кэше сессий параметры сессии, соответствующей данному идентификатору. Более подробно процедура взаимодействия сторон в рамках полной схемы обмена сообщениями описана в 6.2.
Рисунок 3 - Полная схема обмена сообщениями в протоколе Handshake
Примечания
1 На рисунке 3 символом "*" отмечены опциональные сообщения, которые передаются в случае двусторонней аутентификации.
2 Сообщение ChangeCipherSpec и сообщение Application Data формально относятся не к сообщениям протокола Handshake, а к протоколам Change Cipher Spec и Application Data соответственно (см. подробнее раздел 7 и раздел 9).
3 В соответствии с [1] протокол TLS 1.2 допускает возможность установления анонимного соединения без обмена сертификатами, однако в протоколе, соответствующем криптонаборам, описанным в настоящих рекомендациях, данная опция не должна быть использована.
4 В [1] определено также сообщение ServerKeyExchange, которое посылается сервером только в том случае, если в сообщении Certificate сервер указал недостаточно данных для формирования клиентом сообщения ClientKeyExchange (см. 6.4.5). Однако в рамках протокола, соответствующего криптонаборам, описанным в настоящих рекомендациях, сертификат сервера содержит достаточно данных для формирования сообщения ClientKeyExchange, поэтому сообщение ServerKeyExchange пересылаться не должно.
Если клиент хочет создать соединение в рамках существующей сессии, то в сообщении приветствия ClientHello он должен указать идентификатор этой сессии. Если сервер смог найти в кэше сессий параметры сессии, соответствующей данному идентификатору, процесс обмена сообщениями протокола Handshake происходит по упрощенной схеме (см. рисунок 4). Более подробно процедура взаимодействия сторон в рамках упрощенной схемы обмена сообщениями в протоколе Handshake описана в 6.2.
Рисунок 4 - Упрощенная схема обмена сообщениями в протоколе Handshake
Примечание - Сообщение ChangeCipherSpec и сообщение Application Data формально относятся не к сообщениям протокола Handshake, а к протоколам Change Cipher Spec и Application Data соответственно (см. подробнее раздел 7 и раздел 9).
Во время упрощенной схемы работы протокола Handshake стороны не вырабатывают новое общее сессионное секретное значение MS. Для выработки ключевого материала, необходимого для работы протокола Record в рамках устанавливаемого соединения, используется значение MS, выработанное при выполнении полной схемы протокола Handshake, в ходе которой были установлены параметры сессии с данным идентификатором.