Спецификация Internet-сообщества TLS

Протокол передачи записей

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

Спецификациями TLS предусмотрено четыре вышележащих клиента протокола передачи записей:

Функции этих протоколов будут рассмотрены в следующем разделе.

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

Перечислим и другие элементы состояния соединения:

Первоначальное состояние - ожидания - создает протокол установления соединений ; он же ведает переводом отложенных соединений в текущие и наоборот.

Формально процесс обработки данных протоколом передачи записей можно описать как последовательность преобразований структур (в спецификациях для этой цели используется интуитивно понятный C-подобный язык).

На первом шаге выполняется фрагментация (или объединение однотипных) сообщений, предназначенных для передачи, в структуры TLSPlaintext размером не более 16384 байт (см. листинг 10.1).

enum {
  change_cipher_spec(20), alert(21), 
  handshake(22), application_data(23), (255)
} ContentType;

struct {
  ContentType type;
  ProtocolVersion version;
  uint16 length;
  opaque fragment [TLSPlaintext.length];
} TLSPlaintext;

Типы сообщений, поступающих с вышележащих уровней протоколу передачи записей, могут чередоваться, а сами сообщения - создавать очереди. В таком случае прикладные данные имеют наименьший приоритет.

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

struct {
  ContentType type;		
  /* Тот же, что и TLSPlaintext.type */
  
  ProtocolVersion version;	
  /* Та же, что и TLSPlaintext.version */
  
  uint16 length;
  opaque fragment [TLSCompressed.length];
} TLSCompressed;

Далее следуют криптографические операции. К этому моменту на основе мастер-секрета и случайных значений, предоставленных сервером и клиентом, должен быть сгенерирован ключевой блок достаточной длины (см. листинг 10.3).

key_block = PRF 
    (SecurityParameters.master_secret,
     "key expansion", 
     SecurityParameters.server_random +
     SecurityParameters.client_random);
	
/* PRF - псевдослучайная функция */
/* "+" обозначает операцию конкатенации */

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

client_write_MAC_secret 
     [SecurityParameters.hash_size]
server_write_MAC_secret 
     [SecurityParameters.hash_size]
client_write_key 
     [SecurityParameters.key_material_length]
server_write_key 
     [SecurityParameters.key_material_length]

client_write_IV [SecurityParameters.IV_size]
server_write_IV [SecurityParameters.IV_size]

/* MAC - Message Authentication Code, */
/* аутентификационный код сообщения */
/* IV - Initialization Vector, */
/* начальный вектор */

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

HMAC_hash (MAC_write_secret, seq_num + 
  TLSCompressed.type + 
  TLSCompressed.version +
  TLSCompressed.length + 
  TLSCompressed.fragment));

Обратим внимание, что в состав аргумента хэш-функции входит порядковый номер записи для защиты от кражи, дублирования и переупорядочения сообщений.

На четвертом шаге выполняется шифрование блока вместе с имитовставкой (см. листинг 10.6).

stream-ciphered struct {
  opaque content [TLSCompressed.length];
  opaque MAC [CipherSpec.hash_size];
} GenericStreamCipher;

block-ciphered struct {
  opaque content [TLSCompressed.length];
  opaque MAC [CipherSpec.hash_size];
  uint8 padding 
    [GenericBlockCipher.padding_length];
  uint8 padding_length;
} GenericBlockCipher;

struct {
  ContentType type;
  ProtocolVersion version;
  uint16 length;
  select (CipherSpec.cipher_type) {
    case stream: GenericStreamCipher;
    case block: GenericBlockCipher;
  } fragment;
} TLSCiphertext;

На стороне получателя действия выполняются в обратном порядке:

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

Протокол установления соединений и ассоциированные протоколы

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

На рис. 10.1 показан процесс формирования сеанса. Звездочками помечены необязательные сообщения, в квадратные скобки заключено сообщение протокола смены параметров шифрования.

(рис 10.1) Процесс формирования сеанса

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

Новое соединение на основе существующего сеанса формируется более экономным образом (см. рис. 10.2).

(рис 10.2) Формирование нового соединения на основе существующего сеанса

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

Поясним структуру и назначение сообщений, приведенных на рисунках.

Приветственное сообщение клиента, открывающее процесс формирования сеанса или соединения, выглядит следующим образом (см. листинг 10.7).

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

struct {
  ProtocolVersion client_version;
  Random random;
  SessionID session_id;
  CipherSuite cipher_suites<2..2^16-1>;
  CompressionMethod 
     compression_methods<1..2^8-1>;
} ClientHello;

Если идентификатор сеанса (session_id) пуст, имеется в виду формирование нового сеанса; в противном случае устанавливается новое соединение в рамках существующего сеанса. Поля compression_methods и cipher_suites содержат списки предлагаемых клиентом алгоритмов сжатия и криптографии (в порядке убывания приоритетов). Они должны быть построены так, чтобы согласие между клиентом и сервером было заведомо возможным. В частности, в списке алгоритмов сжатия должен фигурировать пустой метод.

Сервер отвечает клиенту собственным приветствием, главное в котором - выбранные алгоритмы сжатия и криптографии (см. листинг 10.8).

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

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

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

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

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

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

Структура сообщения о завершении формирования сеанса (соединения) показана на листинге 10.9.

struct {
  opaque verify_data[12];
} Finished;

Finished.verify_data = PRF (master_secret, 
  finished_label, MD5(handshake_messages) + 
  SHA-1(handshake_messages)) [0..11];

/* Хэшируются все сообщения, участвовавшие в */
/* установлении соединения */
/* Значениями параметра "finished_label" 
/* служат, соответственно, цепочка символов */
/*"client finished" на стороне клиента */
/* и "server finished" на стороне сервера. */

Мастер-секрет вычисляется единообразно для всех методов выработки ключей ( см. листинг 10.10).

master_secret = PRF 
  (pre_master_secret, 
   "master secret", 
   ClientHello.random + ServerHello.random)
	[0..47];

Участвующий в процессе формирования сеанса протокол смены параметров шифрования устроен предельно просто и заключает в себе один тип однобайтных сообщений.

Более содержательный протокол оповещения предназначен для передачи предупреждений и сообщений об ошибках. Наиболее употребительное предупреждение - уведомление о завершении сеанса. Типичные ошибки - неожиданное сообщение, неверная имитовставка, неверный параметр, ошибка расшифрования и т.п. После получения сообщения об ошибке соединение разрывается.

Применение протокола HTTP над TLS

Применение протокола HTTP над TLS описано в спецификациях . С концептуальной точки зрения, оно организовано весьма просто. HTTP/TLS-сервер слушает порт 443. HTTP/TLS-клиент, являясь, в частности, TLS -клиентом, начинает процесс установления соединения с посылки приветственного сообщения. По сформированному TLS -соединению направляются обычные HTTP-запросы и ответы на них, которые трактуются протоколом TLS как прикладные данные.

В уникальном идентификаторе ресурсов (URI) сочетание HTTP/TLS обозначается как "https":

https://www.example.com/home.html

Обычно после анализа URI клиент узнает имя хоста, на котором функционирует сервер. Это имя должно быть сопоставлено с тем, которое фигурирует в сертификате сервера. Если сервер задан IP-адресом, тот же адрес должен присутствовать в сертификате и подвергаться проверке.

В качестве сигнала окончания взаимодействия используется уведомление о завершении сеанса.