13.3. Протокол SSL/TLS

Протокол SSL (англ. Secure Sockets Layer) был разработан компанией Netscape. Начиная с версии 3, протокол развивается как открытый стандарт TLS (англ. Transport Layer Security). Протокол SSL/TLS обеспечивает защищённое соединение по незащищённому каналу связи на прикладном уровне модели TCP/IP. Протокол встраивается между прикладным и транспортным уровнями стека протоколов TCP/IP. Для обозначения «новых» протоколов, полученных с помощью инкапсуляции прикладного уровня (HTTP, FTP, SMTP, POP3, IMAP и т. д.) в SSL/TLS, к обозначению добавляют суффикс «S» («Secure»): HTTPS, FTPS, POP3S, IMAPS и т. д.

Протокол обеспечивает следующее:

Одностороннюю или взаимную аутентификацию клиента и сервера по открытым ключам сертификата X.509. В Интернете, как правило, делается односторонняя аутентификация веб-сервера браузеру клиента, то есть только веб-сервер предъявляет сертификат (открытый ключ и ЭП к нему от вышележащего УЦ).
Создание сеансовых симметричных ключей для шифрования и кода аутентификации сообщения для передачи данных в обе стороны.
Конфиденциальность – блочное или потоковое шифрование передаваемых данных в обе стороны.
Целостность – аутентификацию отправляемых сообщений в обе стороны имитовставкой ${\textrm{HMAC}}(K,M)$, описанной ранее.

Рассмотрим протокол TLS последней версии 1.2.

13.3.1. Протокол «рукопожатия»

Протокол «рукопожатия» (англ. Handshake Protocol) производит аутентификацию и создание сеансовых ключей между клиентом $C$ и сервером $S$.

$C \rightarrow S$:
1. ClientHello: 1) URI сервера, 2) одноразовая метка $N_C$, 3) поддерживаемые алгоритмы шифрования, кода аутентификации сообщений, хеширования, ЭП и сжатия.
$C \leftarrow S$:
1. ServerHello: одноразовая метка $N_S$, поддерживаемые сервером алгоритмы. После обмена набором желательных алгоритмов сервер и клиент по единому правилу выбирают общий набор алгоритмов.
2. Server Certificate: сертификат X.509v3 сервера с запрошенным URI (URI нужен в случае нескольких виртуальных веб-серверов с разными URI на одном узле c одним IP-адресом).
3. Server Key Exchange Message: информация для создания предварительного общего секрета $premaster$ длиной 48 байтов в виде: 1) обмена по протоколу Диффи — Хеллмана с клиентом (сервер отсылает $(g, g^a)$), 2)Обмена по другому алгоритму с открытым ключом, 3) разрешения клиенту выбрать ключ.
4. Электронная подпись к Server Key Exchange Message на ключе сертификата сервера для аутентификации сервера клиенту.
5. Certificate Request: опциональный запрос сервером сертификата клиента.
6. Server Hello Done: идентификатор конца транзакции.
$C \rightarrow S$:
1. Client Certificate: сертификат X.509v3 клиента, если он был запрошен сервером.
2. Client Key Exchange Message: информация для создания предварительного общего секрета $premaster$ длиной 48 байтов в виде: 1) либо обмена по протоколу Диффи — Хеллмана с сервером (клиент отсылает $g^b$, в результате обе стороны вычисляют ключ $premaster = g^{ab}$), 2) либо обмена по другому алгоритму, 3) либо ключа, выбранного клиентом и зашифрованного на открытом ключе из сертификата сервера.
3. Электронная подпись к Client Key Exchange Message на ключе сертификата клиента для аутентификации клиента серверу (если клиент использует сертификат).
4. Certificate Verify: результат проверки сертификата сервера.
5. Change Cipher Spec: уведомление о смене сеансовых ключей.
6. Finished: идентификатор конца транзакции.
$C \leftarrow S$:
1. Change Cipher Spec: уведомление о смене сеансовых ключей.
2. Finished: идентификатор конца транзакции.

Одноразовая метка $N_C$ состоит из 32 байтов. Первые 4 байта содержат текущее время (gmt

<_>

unix

<_>

time), оставшиеся байты – псевдослучайную последовательность, которую формирует криптографически стойкий генератор псевдослучайных чисел.

Предварительный общий секрет $premaster$ длиной 48 байтов вместе с одноразовыми метками используется как инициализирующее значение генератора $PRF$ для получения общего секрета $master$, тоже длиной 48 байтов:

$$ master = PRF(premaster, ~\text{текст \textquotedblleft master secret\textquotedblright}, ~ N_C + N_S) .$$

И, наконец, уже из секрета $master$ таким же способом генерируется 6 окончательных сеансовых ключей, следующих друг за другом в битовой строке:

$$ \{ (K_{E,1} ~\|~ K_{E,2}) ~\|~ (K_{{\textrm{MAC}},1} ~\|~ K_{{\textrm{MAC}},2}) ~\|~ (IV_1 ~\|~ IV_2) \} = $$

$$ = PRF(master, ~\text{текст \textquotedblleft key expansion\textquotedblright}, ~ N_C + N_S), $$

где $K_{E,1}$, $K_{E,2}$ – два ключа симметричного шифрования, $K_{{\textrm{MAC}},1}$, $K_{{\textrm{MAC}},2}$ – два ключа имитовставки, $IV_1$, $IV_2$ – два инициализирующих вектора режима сцепления блоков. Ключи с индексом 1 используются для коммуникации от клиента к серверу, с индексом 2 – от сервера к клиенту.

13.3.2. Протокол записи

Протокол записи (англ. Record Protocol) определяет формат TLS-пакетов для вложения в TCP-пакеты.

Исходными сообщениями $M$ для шифрования являются пакеты протокола следующего уровня в модели OSI: HTTP, FTP, IMAP и т. д.
Сообщение $M$ разбивается на блоки $m_i$ размером не более 16 кибибайт.
Блоки $m_i$ сжимаются алгоритмом компрессии в блоки $z_i$.
Вычисляется имитовставка для каждого блока $z_i$ и добавляется в конец блоков: $a_i = z_i ~\|~ {\textrm{HMAC}}(K_{{\textrm{MAC}}}, z_i)$.
Блоки $a_i$ шифруются симметричным алгоритмом с ключом $K_E$ в некотором режиме сцепления блоков с инициализирующим вектором $IV$ в полное сжатое аутентифицированное зашифрованное сообщение $C$.
К шифртексту $C$ добавляется заголовок протокола записи TLS, в результате чего получается TLS-пакет для вложения в TCP-пакет.