Протокол TLS

Сообщение зашифрованного RSA предмастерного секретного кода

Если для согласования ключей и аутентификации применен алгоритм RSA, клиент генерирует 48-байтовый предмастерный секретный код, шифрует его с помощью общедоступного ключа из сертификата сервера или временного RSA -ключа, переданного в сообщении ключевого обмена сервера, и посылает результат в сообщении зашифрованного предмастерного секретного кода (encrypted premaster secret). Эта структура является вариантом сообщения ключевого обмена клиента.

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

struct { ProtocolVersion client_version; opaque random[46];} 
  PreMasterSecret;

struct{public-key-encrypted PreMasterSecret pre_master_secret;} 
   EncryptedPreMasterSecret;

Атака, рассмотренная Даниэлем Блайхенбахером (Daniel Bleichenbacher) [BLEI], может быть предпринята против TLS -сервера, который использует PKCS#1, закодированный с помощью RSA.

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

Общедоступный Diffie-Hellman-ключ клиента

Эта структура передает общедоступную величину ( Yc ) алгоритма Диффи-Хелмана для клиента, если она не была уже включена в сертификат клиента. Шифрование, используемое для Yc, определяется нумерованным параметром PublicValueEncoding. Эта структура является вариантом сообщения ключевого обмена клиента. Структура этого сообщения имеет вид:

enum { implicit, explicit } PublicValueEncoding;

struct { select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>; } dh_public;
} ClientDiffieHellmanPublic;

Верификация сертификата

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

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

struct { Signature signature; } CertificateVerify;
CertificateVerify.signature.md5_hash MD5(handshake_messages);
Certificate.signature.sha_hash SHA(handshake_messages);

Здесь handshake_messages относятся ко всем сообщениям диалога, посланным или полученным, начиная с hello клиента и вплоть до (но исключая) данное сообщение, содержащее поля типа и длины сообщений диалога. Это представляет собой соединение всех структур диалога.

Сообщение Finished

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

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

struct { opaque verify_data[12];} finished;

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

Хэши, которые содержатся в сообщениях finished, посланных серверам, включают в себя Sender.server ; а посланные клиентом содержат Sender.client. Значение handshake_messages включает все сообщения диалога, начиная с hello клиента и вплоть до (но не включая) сообщения finished. Следует иметь в виду, что handshake_messages для сообщения finished, посланного клиентом, будет отличаться от посланного сервером, так как второе включает первое.

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

Криптографические вычисления

Для того чтобы начать защиту соединения, протоколу записей TLS необходима спецификация набора алгоритмов, мастерный секретный код и случайные коды клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются cipher_suite, выбранным сервером и указанным в сообщении server hello. Алгоритм сжатия согласуется в сообщениях hello, а случайные коды пересылаются в сообщениях hello. Все что остается — это вычислить мастерный секретный код.

Вычисление мастерного секретного кода

Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret.

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

Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена.

RSA

Когда для аутентификации сервера и ключевого обмена применяется RSA, 48-байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше.

Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2.

Diffie-Hellman

Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ ( Z ), преобразование его в master_secret, описано выше.

Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.

В отсутствие стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

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