Протокол TLS

Протокол диалога

Протокол диалога TLS представляет собой один из фиксированных клиентских протоколов высокого уровня (записей) TLS. Этот протокол используется для согласования атрибутов безопасности сессии. Сообщения диалога передаются уровню записей TLS, где они инкапсулируются в одну или более структур TLSPlaintext, которые обрабатываются и передаются так, как это специфицировано текущим состоянием активной сессии.

enum { hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct { HandshakeType msg_type; /* тип диалога */
         uint24 length;          /* байтов в сообщении */
         select (HandshakeType) {
         case hello_request: HelloRequest;
         case client_hello: ClientHello;
         case server_hello: ServerHello;
         case certificate: Certificate;
         case server_key_exchange: ServerKeyExchange;
         case certificate_request: CertificateRequest;
         case server_hello_done: ServerHelloDone;
         case certificate_verify: CertificateVerify;
         case client_key_exchange: ClientKeyExchange;
         case finished: Finished; } body;
         } Handshake;

Сообщения протокола диалога представлены ниже в порядке, в котором они должны быть посланы. Посылка сообщений диалога в неправильном порядке приведет к фатальной ошибке. Ненужные сообщения диалога могут быть опущены. Обратите внимание на одно исключение: сообщение сертификата используется в диалоге дважды (от клиента к серверу, а затем от сервера к клиенту), но оно описано лишь для первого случая его использования. Одно сообщение не привязано к этим правилам порядка обмена, — это сообщение запроса Hello, которое может быть послано в любое время, но которое должно игнорироваться клиентом, если приходит в середине диалога.

Сообщения Hello

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

Запрос Hello

Сообщение-запрос hello может быть послано сервером в любое время. Запрос Hello является простым уведомлением о том, что клиент должен начать согласование параметров путем посылки сообщения client hello. Это сообщение будет проигнорировано клиентом, если он участвует в сессии согласования или если он не хочет заново согласовывать параметры сессии, или клиент может, если хочет, реагировать уведомлением no_renegotiation. Так как сообщения диалога предназначены для осуществления определенных действий над прикладными данными, ожидается, что согласование начнется до того, как будут получены новые записи от клиента. Если сервер посылает запрос hello, но не получает отклика client hello, он может разорвать соединение с фатальным уведомлением.

После посылки запроса hello серверы не должны повторять запрос до тех пор, пока диалог согласования не завершится.

Структура этого сообщения: struct { } HelloRequest;

Это сообщение не должно никогда включаться в хэши сообщений и использоваться в завершающих сообщениях ( finished ), а также в сообщении верификации сертификатов.

Hello клиента

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

Сообщение hello клиента включает в себя случайную структуру, которая позднее используется протоколом.

struct { uint32 gmt_unix_time; opaque random_bytes[28];} Random;

Сообщение client hello включает в себя идентификатор сессии переменной длины. Если это поле не пусто, его значение идентифицирует сессию, чьи параметры безопасности клиент желает использовать повторно. Идентификатор сессии может соответствовать какому-то предшествующему соединению, текущему соединению, или другому активному соединению. Вторая опция полезна, если клиент хочет изменить случайные структуры и получить текущие значения параметров соединения, в то время как третья опция делает возможным установить несколько независимых безопасных соединений без повторения всей процедуры протоколы диалога. Эти независимые соединения могут существовать последовательно или одновременно; SessionID становится действенным, когда диалог согласования завершается обменом сообщениями Finished, и сохраняется до тех пор, пока не состарится или пока не произойдет фатальная ошибка. Действительное содержимое SessionID определяется сервером.

opaque SessionID<0..32>;

Так как SessionID передается без шифрования или MAC-защиты, серверы не должны помещать конфиденциальные данные в идентификаторы сессий, что могло бы привести к возрастанию уязвимости. Заметим, что содержимое диалога в целом, включая SessionID, защищено сообщениями Finished, пересылаемыми в конце диалога.

Список CipherSuite, передаваемый от клиента серверу в сообщении client hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом в порядке их предпочтения (предпочтительный вариант — первый). Каждый CipherSuite определяет алгоритм пересылки ключей, алгоритм массового шифрования (включая длину секретного ключа) и алгоритм MAC. Сервер выберет шифровой набор или, если приемлемого варианта нет, пришлет уведомление об ошибке и прервет соединение.

uint8 CipherSuite[2]; /* Селектор криптографического набора */

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

enum { null(0), (255) } CompressionMethod;
struct { ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..216-1>;
       CompressionMethod compression_methods<1..28-1>;
       } ClientHello;

После посылки сообщения client hello клиент ждет сообщения server hello. Любое другое сообщение диалога, присланное сервером, рассматривается как фатальная ошибка.

В интересах прямой совместимости, клиенту разрешено включать в сообщение client hello после методов сжатия дополнительные данные. Эти данные должны быть включены в хэши диалога, в противном случае они игнорируются. Hello — единственное сообщение диалога, для которого это допускается; для всех остальных сообщений объем данных должен точно соответствовать описанию сообщения.

Hello сервера

Сервер посылает это сообщение в ответ на сообщение client hello, когда он может найти приемлемый набор алгоритмов. Если он не может сделать приемлемый выбор, он реагирует уведомлением об ошибке диалога.

Структура этого сообщения:

Struct { ProtocolVersion server_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suite;
       CompressionMethod compression_method;
       } ServerHello;