Опубликован: 10.10.2007 | Уровень: специалист | Доступ: платный
Лекция 16:

Протокол 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;
gmt_unix_time Текущее время и дата в соответствии со стандартом UNIX в 32-битовом формате (число секунд с момента полуночи 1-го января, 1970, GMT) согласно показаниям внутренних часов отправителя. Часы могут и не быть точно выверены на уровне протокола TLS. Прикладные протоколы могут накладывать дополнительные ограничения.
random_bytes 28 байт сформированных безопасным генератором случайных чисел.

Сообщение 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_version Версия протокола TLS, которой хочет воспользоваться клиент во время сессии. Это должна быть последняя версия (с наибольшим кодом), поддерживаемая клиентом. Для данной спецификации значение версии равно 3.1.
Random Псевдослучайная структура, генерируемая клиентом.
session_id ID-сессия, которую клиент хочет использовать для данного соединения. Это поле должно быть пустым, если нет ни одного session_id или клиент хочет выработать новые параметры безопасности.
cipher_suites Список криптографических опций, поддерживаемых клиентом в порядке предпочтения. Если поле session_id не пусто (запрос восстановления сессии), этот вектор должен включать, по крайней мере, cipher_suite данной сессии.
compression_methods Список методов сжатия, поддерживаемых клиентом в порядке их предпочтения. Если поле session_id не пусто (запрос восстановления сессии) он должен включать compression_method данной сессии. Этот вектор должен содержать, а все реализации должны поддерживать CompressionMethod.null. Таким образом, клиент и сервер всегда могут согласовать метод сжатия информации.

После посылки сообщения 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;
server_version Это поле будет содержать самое низкое значение, которое предлагается клиентом в client hello, и наибольшее значение версии, поддерживаемое сервером. Значение версии данной спецификации равно 3.1.
Random Эта структура генерируется сервером и должна быть отличной от ClientHello.random.
session_id Идентифицирует сессию, соответствующую данному соединению. Если ClientHello.session_id не пусто, сервер будет искать соответствие с содержимым своего кэша сессий. Если соответствие найдено и сервер хочет установить новое соединение, используя специфицированное состояние сессии, он откликнется тем же значением ID, что было прислано клиентом. Это индицирует возобновляемую сессию. Партнеры должны продолжить обмен сообщениями finished. В противном случае, это поле будет содержать другое значение, идентифицирующее новую сессию. Сервер может вернуть пустое поле session_id, чтобы индицировать, что сессия не кэшируется и, следовательно, не может быть возобновлена. Если сессия возобновлена, она должна использовать тот же шифровой набор, который был согласован ранее.
cipher_suites Шифровой набор, выбранный сервером из списка в ClientHello.cipher_suites. Для возобновленных сессий это поле несет в себе значение, взятое из состояния возобновляемой сессии.
Compression_method Алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для возобновляемых сессий это поле содержит значение из состояния возобновляемой сессии.
Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Нияз Сабиров
Нияз Сабиров

Здравствуйте. А уточните, пожалуйста, по какой причине стоимость изменилась? Была стоимость в 1 рубль, стала в 9900 рублей.

Роман Ижванов
Роман Ижванов
Россия, Университет природы, общества и человека «Дубна»
Анастасия Шмакова
Анастасия Шмакова
Россия, Тольятти, ПВГУС, 2013