What is: SSL/TLS в деталях

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

Два наиболее часто встречающихся набора протоколов – SSL/TLS, основная задача которых заключается в обеспечении конфидициальности передаваемых данных, обеспечении целостности данных (т.е. гарантирование того, что данные не были изменены или подменены во время доставки между узлами), а так же в обеспечении идентификации и аутенфикации ресурсов и хостов с использованием цифровых сертификатов.

Каждый протокол SSL/TLS включает в себя набор внутренних протоколов (subprotocols), которые рассмотрены в разделе Обзор SSL/TLS соединения.

Задачи SSL/TLS соединения:

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

Ниже будут рассмотрены основные аспекты SSL/TLS. К сожалению, как бы ни хотелось – всего описать не получится, но постарался собрать и хотя бы кратко описать самое важное (плюс ссылки в тексте и в конце поста).

TSL vs SSL: история

Основное отличие между ними – TLS является наследником протокола SSL, и использует более безопасные способы обеспечения безопасности.

Аббревиатуры:

SSL – Secure Socket Layer
TLS – Transport Layer Security

Краткая история SSL/TLS:

SSL был разработан компанией Netscape, но версия 1.0 не была опубликована и использована из-за проблем безопасности в её реализации
SSL 2.0 была выпущена в феврале 1995, но так же содержала уязвимости, потому:
в 1996 появилась версия SSL 3.0

SSL 2.0 официально признан устаревшей версией в 2011 году (см. RFC 6176), а SSL 3.0 – в 2015 (RFC 7568), хотя версия 3.0 была объявлена небезопасной для использования ещё в 2004 году из-за обнаружения уязвимости POODLE.

Из-за проблем с безопасностью, а так же из-за проблем с Netscape, связанных с юридическими вопросами, в 1999 на смену SSL пришёл протокол TLS, основанный на SSL v3.0.

TLS являлся окрытым стандартном (в отличии от SSL, поддерживаемого компанией Netscape) и в результате полностью заменил собой SSL.

TLS 1.0 выпущен в январе 1999, RFC 2246, и использовался вплоть до 2016 года, когда первый раз был объявлен устаревшим (позже его “устаревание” продлили до 2018 года).
TSL 1.1 выпущен в апреле 2006, RFC 4346, с 30-го июня 2018 полностью заменит TLS 1.0
TLS 1.2 появился в августе 2008, RFC 5246, с 30-го июня 2018 полностью заменит TLS 1.0 и будет являться рекомендуемым протоколом для использования
TLS 1.3 ещё находится в состоянии черновика

Аббревиатуры SSL и TLS используются взаимозаменяемы, и под SSL как правило подразумевается TLS, т.к. в большистве случаев (а особенно в 2018) клиенты предлагают (см ClientHello) использовать версии TLS 1.1 и 1.2.

По теме:

SSL/TLS: основные понятия

Прежде, чем перейти к соединению и TLS Handshake части – рассмотрим некоторые основные понятия.

SSL certificate

Сертификат открытого ключа (public key certificate, digital certificate или identity certificate, а так же сертификат, сертификат ключа подписи, сертификат ключа проверки электронной подписи) – электронный документ, подтверждающий принадлежность публичного ключа его владельцу.

Сертификат выдаётся и подписывается Certificate Authorities, которые подписывают выданные сертификаты своей цифровой подписью, подтверждая, что владелец сертификата (и публичного ключа, включённого в этот сертификат) был проверен:

TLS сертификат как правило включает в себя поля:

Version Number: версия сертификата ( см X.509)
Serial Number: используется для идентификации сертификата его Certificate Authorities
Signature Algorithm: алгоритм, использованный для подписи публичного ключа
Issuer: кем выдан и подписан сертификат (Certificate Authority)
Not Before и Not After: срок действия (валидности) сертификата
Subject name: кому принадлежит сертификат
Subject Public Key Info
- Public Key Algorithm: алгоритм, использованный для подписи публичного ключа
- Subject Public Key: сам публичный ключ владельца сертификата
Certificate Signature Algorithm: алгоритм, использованный для подписи сертификата
Certificate Signature: цифровая подпись сертификата

Например сертификат для RTFM выглядит так:

[simterm]

$ echo | openssl s_client -servername rtfm.co.ua -connect rtfm.co.ua:443 2>/dev/null | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:af:86:47:72:69:53:70:5b:ee:b6:76:73:a6:f3:56:8f:f4
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Feb  6 09:07:34 2018 GMT
            Not After : May  7 09:07:34 2018 GMT
        Subject: CN = rtfm.co.ua
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b2:05:69:79:41:19:b7:43:50:d9:03:a9:50:b7:
                    ...
            X509v3 Subject Alternative Name:
                DNS:rtfm.co.ua, DNS:www.rtfm.co.ua
            ...
    Signature Algorithm: sha256WithRSAEncryption
         49:1c:cc:48:f3:8c:6e:05:7e:c7:94:bf:33:e0:05:d7:98:11:
         ...

[/simterm]

Получить только публичный ключ из сертификата можно так:

[simterm]

$ openssl s_client -servername rtfm.co.ua -connect rtfm.co.ua:443 | openssl x509 -pubkey -noout 2>/dev/null
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = rtfm.co.ua
verify return:1
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgVpeUEZt0NQ2QOpULcJ
8Pe2pTpTFzflNfeMOLT2tFUKFPkEU4Qasu5FoL1p5RzWyGh8kOu7sN5F6Up5U1V+
5EAghuG8amGcx3oUXSDlv/TUkesiVPtYil87qfj8q5Sm561oTx4Q5pch2JWYyWjb
uCIRNeB7FuA+Ts7iEfIc1dXtj2wHIp6wqwsCcBPa/xFUAjN1yWc2+rmZSs4ctaEL
9BwVx3kMhwkWsU4nwEQygGZR+ofeVjKIxu2fjWLhlX9xx4LQePO+fNTu4iMOrVok
M4Ch/T33Z44bxjGwsaMY7tZgMZhbPRBhAkA8RNx8f1Jmk/tSQOMFkghsdaq7kVP4
FwIDAQAB
-----END PUBLIC KEY-----

[/simterm]

CipherSuites

Cipher suite – это комбинация криптографических алгоритмов, которые будут использованы для обеспечения безопасности сессии.

Как правило, в неё входят алгоритмы для:

алгоритм обмена ключами
аутентификации сервера
шифрования данных
алгоритм контроля целостности (Message Authentication Code, MAC)

Например – для соединения с RTFM клиент (браузер) выбирает набор TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:

Тут:

TLS: используемый протокол
ECDHE: алгоритм обмена ключами сессии (Elliptic curve Diffie–Hellman ephemeral)
RSA: алuоритм аутентификации (RSA)
AES_256_GCM: алгоритм шифрования данных (Advanced Encryption Standard 256 bit Galois/Counter Mode)
SHA384: алгоритм Message Authentication Code (MAC) (Secure Hash Algorithm 384 bit)

См. по теме:

Message Authentication Code (MAC)

Message Authentication Code, или криптографическая контрольная сумма сообщения – способ аутентификации и проверки целостности сообщения, основанный на цифровой подписи сообщения (или блока данных на Record Layer).

Подпись создаётся с помощью секретного ключа (client_write_MAC_key и server_write_MAC_key в ChangeCipherSpec и Finish) и самого сообщения.

Hash Based Message Authentication Code (HMAC) – тип MAC, основанный на хешировании (hash function).

Пример получения такой контрольной суммы с использованием SHA384:

[simterm]

$ echo -n "message" | openssl dgst -sha384 -hmac "client_write_MAC_key"
(stdin)= b7d9a7f344e90379bc16123754d17697b0c5cd86bb524fd11cda9654c245773eb7503457f59a2e748259539a563af259

[/simterm]

Симметричное шифрование

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

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

Если этот ключ будет перехвачен злоумышленником – он получит возможность расшировать все данные, зашифрованные этим ключём.

Именно поэтому передача такого ключа должна осуществляться по уже зашированному соединению.

Преимущества

быстрое, низкое потребление ресурсов системы
простые операции
безопасно

Недостатки

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

Ассиметричное шифрование

Asymmetric encryption (также Public Key Cryptography – криптография по открытому ключу) использует пары ключей – публичный и приватный. Эти ключи связаны друг с другом таким образом, что данные, зашифрованные с помощью одного ключа (как правило публичного) могут быть расшифрованы другим (приватным).

Асссиметричное шифрование так же может применяться для авторизации отправителя: если Боб подписывает и шифрует сообщение, используя свой приватный ключ, то любой, у кого есть публичная часть ключа и кто смог расшифровать такое сообщение может быть уверен, что его зашифровал и отправил только Боб (при условии, что Боб не слил свой приватный ключ в Github…).

Преимущества

простая передача ключа
аутентификация пользователей
проверка целостности

Недостатки

медлененее, чем симметричное шифрование
потребляет больше ресурсов

Теперь можно перейти к рассмотрению непосредственно SSL/TLS соединения.

Обзор SSL/TLS соединения

Любое SSL-соединение использует набор протоколов, описанных в RFC 5246 (тут и ниже рассматривается TLS v 1.2 и этот RFC, как последняя актуальная версия на момент написания этого поста – март 2018).

В RFC 5246 они описаны в обратном порядке, но тут рассмотрим их начиная с Handshake Protocol, т.к. именно в нём описывается процесс установления сессии и создания ключей, которые далее используются в TLS Record Protocol.

Структура получается следующая:

The TLS Handshaking Protocols
- Handshake Protocol
- Change Cipher Spec Protocol
- Alert Protocol
The TLS Record Protocol
- Record Layer

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

TLS Handshaking Protocols

Описан в разделе 7 RFC.

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

Опять-таки – в RFC они описаны в другом порядке, но тут для удобства понимания кратко рассмотрим их в порядке “важности” – Handshake Protocol, Change Cipher Spec Protocol и Alert Protocol.

Выполняется на Presentation Layer модели OSI:

Handshake Protocol

Описан в разделе 7.4 RFC 5246.

Ключевой протокол, описывающий процесс установления сессии и согласования параметров, которые будут использоваться во время сессии. Он включает в себя 9 основных “сообщений рукопожатия” (handshake messages), которые используются для создания сессии – их мы в деталях и рассмотрим далее (Процесс установления SSL сессии – базовый SSL Handshake).

Эти сообщения передаются на TLS Record layer, который передаёт далее, вниз по стеку протоколов OSI.

Change Cipher Spec Protocol

Описан в разделе 7.1.

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

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

Alert Protocol

Описан в разделе 7.2.

Этот протокол описывает Alert тип данных, в котором передаются сообщения для управления соединением. Алерты содержат два поля – уровень предупреждения и его описание.

Уровень fatal приводит к немедленному уничтожению соединения. В этому случае другие соединения в этой сессии (см. C: libssh – пример SSH-“клиента”) могут оставаться активными до их завершения, но идентификатор сессии (Session ID, будет рассмотрен ниже) должен быть удалён, предотвращая создание новых соединений в рамках этой сессиии.

The TLS Record Protocol

Описан в разделе 6.

TLS Record Protocol включает принимает сообщения для передачи от Application Layer модели OSI, разбивает их на блоки, при необходимости выполняет сжатие, добавляет Message authentication code (MAC), выполняет шифрование и передаёт результат вниз по стеку на TCP протокол.

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

TLS Record Protocol выполняется над Transport Layer, который обеспечивает передачу блоков данных между узлами сети, и под Application уровнем, обеспечивая передачу данных приложениям:

Record Layer

На TLS Record Layer выполняется фрагментация (6.2.1), сжатие и распаковка (6.2.2) и защита целостности (6.2.3) передаваемых данных.

Процесс установления SSL сессии – SSL Handshake

Ключевой момент установления защищенного соединения – SSL Handshake, или “рукопожатие”, в процессе которого осуществляется согласование используемой версии TLS, верификация узлов (аутентификация сервера и опционально клиента), алгоритмов шифрования, обмен ключами, сертификатами и собственно установдение и начало обмена уже зашифрованными данными.

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

Выше упоминалось про 9 сообщений при выполнении TLS Handshake – они предоставлены на изображении ниже:

SSL Handshake кратко

Прежде, чем углубиться в детали реализации TLS Handshake – рассмотрим процесс кратко.

Процесс рукопожатия можно разбить на три условных фазы – привествие (Hello), обмен сертификатами (Certificate Exchange) и обмен ключами (Key Exchange):

Hello: рукопожатие начинается с того, что клиент, который хочет подключиться к серверу используя TLS, отправляет сообщение ClientHello. В нём содержится вся информация, необходимая для создания (или восстановления) TLS-сессии, например – наборы предпочитаемых методов шифрования (Cipher Suites), версия SSL/TLS и т.д. Сервер в свою очередь отвечает сообщением ServerHello, в котором содержится информация, основанная на запросе клиента, например выбранная сервером версия SSL/TLS, ID создаваемой сессии, выбранный метод шифрования.
Certificate Exchange: после того, как контакт установлен – сервер должен доказать клиенту, что он именно тот, за кого он себя выдаёт – пройти аутентификацию, которая выполняется с помощью предоставления сервером SSL сертификата. В сертификате содержится информация о владельце, домене, на который выдан, публичный ключ, цифровая подпись, дата выдачи срок действия сертификата. Клиент выполняет проверку сертификата – либо он может доверять ему безоговорночно, либо может выполнить проверку через Certificate Authorities (CA), которым клиент доверяет. Сервер так же может запросить сертификат клиента для его аутентификации.
Key Exchange: шифрование передаваемых по защищённому соединению данных выполняется с помощью симметричного шифрования, которое было согласовано во время Hello фазы. Симметричное шифрование использует один ключ для шифрования и дешифрования, в отличии от ассиметричного шифрования, в котором используется пара публичного/приватного ключей. Обеим сторонам – клиенту и серверу, необходимо создать ключ для симметричного шифрования (“master key“), а процесс его создания выполняется с помощью ассиметричного шифрования и приватного/публичного ключа сервера плюс рандомные строки, созданные во время Hello фазы.

Далее клиент генерирует pre-master secret key, который будет использоваться для вычисления master key, шифрует его с помощью выбранного в Hello фазе алгоритма используя публичный ключ севера, который передаётся в его сертификате в фазе Certificate Exchange и отправляет его серверу.

Сервер дешифрует pre-master secret key, используя свой приватный ключ и вычисляет master key на своей стороне.

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

SSL Handshake в деталях

Hello, фаза согласования

`ClientHello`

Клиент отправляет ClientHello сообщение серверу, в котором указываются:

client_version: желаемая клиентом версия TLS (последняя из доступных – This SHOULD be the latest (highest valued) version supported by the client)
random: структура, содержащая:
- gmt_unix_time – 4 байта, текущие время и дата в стандартном 32-х битном UNIX формате
- random_bytes – 28 байт, сгенерированные с помощью генератора случайных чисел (random number generator, RNG)
```
struct {
    uint32 gmt_unix_time;
    opaque random_bytes[28];
} Random;
```
session_id: ID сессии, если клиент пытается возобновить TLS сессию
cipher_suites: поддерживаемые CipherSuites (методы шифрования, см. Appendix A.5), с указанием методов, предпочитаемых клиентом.
compression_methods: список методов сжатия, поддерживаемых клиентом (см. RFC-3749 – Transport Layer Security Protocol Compression Methods)
extensions: (опционально) клиент может запросить расширенную функциональность от сервера, указав её в этом поле (см. Hello Extensions)

Сама структура ClientHello (см. Appendix-A.4.1):

   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;

ClientHello описывается в разделе 7.4.1.2.

Пример ClientHello в Wireshark для RTFM:

`ServerHello`

Сервер отвечает сообщением ServerHello, в котором указываются:

server_version: выбранная сервером версия TLS, основываясь на переданном значении client_version из ClientHello
random: аналогично random клиента – 4 байта времени и даты на сервере + 28 байта случайного числа. random клиента и random сервера далее будут использованы для генерации ключа шифрования
session_id: если поле ClientHello.session_id содержало ID сессии – сервер проверит свой кеш на предмет поиска этого ID. Если ID найден – дальнейшие шаги будут пропущены, и рукопожатие перейдёт сразу к стадии Finished.
cipher_suite: метод шифрования, выбранный сервером из списка, предложенного клиентом в его ClientHello.cipher_suite
compression_method: метод сжатия, выбранный из ClientHello.compression_methods. Если сессия восстанавливается (в кеше сервера найдён session_id) – использует метод из старой сессии
extensions: список расширений из списка, отправленного клиентом

Структура ServerHello:

      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

Описывается в разделе 7.4.1.3.

ServerHello в Wireshark:

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

Certificate Exchange, обмен сертификатами

`Certificate`

Сервер отправляет сообщение Certificate, в котором в поле certificate_list передаётся список сертификатов (certificate chain), где первым идёт сертификат самого сервера, за ним сертификаты цепочки доверия (chain of trust) в порядке очереди. Корневые сертификаты не передаются, т.к. предполагается, что клиент уже ими располагает.

Например – в Linux они располагаются в каталоге /etc/ssl/certs/:

[simterm]

$ ls -l /etc/ssl/certs | head -5
total 1384
lrwxrwxrwx 1 root root   64 Mar 12 12:12 00673b5b.0 -> ../../ca-certificates/extracted/cadir/thawte_Primary_Root_CA.pem
lrwxrwxrwx 1 root root   83 Mar 12 12:12 02265526.0 -> ../../ca-certificates/extracted/cadir/Entrust_Root_Certification_Authority_-_G2.pem
lrwxrwxrwx 1 root root   61 Mar 12 12:12 02756ea4.0 -> ../../ca-certificates/extracted/cadir/Certplus_Root_CA_G1.pem
lrwxrwxrwx 1 root root   74 Mar 12 12:12 03179a64.0 -> ../../ca-certificates/extracted/cadir/Staat_der_Nederlanden_EV_Root_CA.pem

[/simterm]

У браузеров политика валидации сертификатов и поиска корневых сертификатов отличается. Для Chrome/Crhomium – см тут>>> и тут>>>.

Сообщение Certificate описывается в разделе 7.4.2.

Certificate в результатах Wireshark:

Тут хорошо просматривается цепочка:

сертификат сервера RTFM: Certificate: (id-at-commonName=rtfm.co.ua)
который пописан Certificate: (id-at-commonName=Let’s Encrypt Authority X3,id-at-organizationName=Let’s Encrypt,id-at-countryName=US)
а сертификат Let’s Encrypt Authority выдан и подписан (id-at-commonName=DST Root CA X3,id-at-organizationName=Digital Signature Trust Co.)

Корневой сертификат DST Root CA X3 расположен в системе, в /etc/ssl/certs:

[simterm]

$ ls -l /etc/ssl/certs/ | grep DST_Root
lrwxrwxrwx 1 root root   56 Mar 12 12:12 12d55845.0 -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem
lrwxrwxrwx 1 root root   56 Mar 12 12:12 2e5ac55d.0 -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem
lrwxrwxrwx 1 root root   56 Mar 12 12:12 DST_Root_CA_X3.pem -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem

[/simterm]

`ServerKeyExchange`

Cервер отправляет сообщение ServerKeyExchange, опционально, в зависимости от используемого алгоритма шифрования для передачи ключа, если данных в сообщении Certificate недостаточно для создания pre-master secret ключа (т.е. в случае использования DHE_DSS, DHE_RSA, DH_anon, другие алогритмы должны явно указать на необходимость передачи ServerKeyExchange).

В ServerKeyExchange может передаваться публичный ключ Diffie-Hellman (DF), с помощью которого клиент может завершить обмен pre-master ключём

Описывается в 7.4.3.

Публичный ключ DF в сообщенииServerKeyExchangeв результатах Wireshark:

`ServerHelloDone`

Сервер отправляет сообщение ServerHelloDone, которое указывает на то, что сервер закончил передачу своего ServerHello и ждёт ответа клиента.
После получения ServerHelloDone клиент выполняет проверку цифровой подписи сертификата сервера (Digital signatures in SSL and TLS), проверяет цепочку сертификатов (How certificate chains work), дату выдачи и срок действия сертификата, и статус сертификата – не был ли он отозван Central Authority, который выдал этот сертификат (Working with revoked certificates).

ServerHelloDone в Wireshark:

`ClientKeyExchange`

Клиент отправляет сообщение ClientKeyExchange, в котором вырабатывается pre-master secret key.

В случае использования RSA – pre-master ключ отправляется серверу зашифрованным с помощью публичного ключа сервера. В случае использования алгоритма Diffie-Hellman – передаются DF параметры со стороны клиента, позволяющие согласовать pre-master ключ.

В случае использования EDF (ephemeral Diffie-Hellman) – клиент передаёт публичный ключ. В случае использования DF (static Diffie-Hellman) – поле ClientDiffieHellmanPublic передаётся пустым.

Структура ClientKeyExchange:

      struct {
          select (KeyExchangeAlgorithm) {
              case rsa:
                  EncryptedPreMasterSecret;
              case dhe_dss:
              case dhe_rsa:
              case dh_dss:
              case dh_rsa:
              case dh_anon:
                  ClientDiffieHellmanPublic;
          } exchange_keys;
      } ClientKeyExchange;

Описывается в разделе 7.4.7.

Wireshark и публичный ключ клиента для DF:

На этом фаза Key Exchange завершена, и начинается процесс “активации” защищённого соединения.

ChangeCipherSpec и Finish

Обе стороны – и клиент, и сервер, вычисляют общий master key длиной 48 байт, используя строки из ClientRandom и ServerRandom + pre_master_secret, используя Pseudorandom Function (PRF):

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

Далее этот master_key используется для генерации набора ключей (см. 6.3. Key Calculation):

client_write_MAC_key – аутентификация и проверка целосности данных клиентом
server_write_MAC_key – аутентификация и проверка целосности данных сервером
client_write_key – шифрование сообщения клиентом, используя симметричный ключ
server_write_key – шифрование сообщения сервером, используя симметричный ключ
client_write_IV – Initialization Vector используемый некоторыми AEAD алгоритмами
server_write_IV –Initialization Vector используемый некоторыми AEAD алгоритмами

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

Клиент отправляет серверу сообщение ChangeCipherSpec, указывая серверу на то, что все данные, начиная с этого сообщения, будут зашифрованы.

После отправки ChangeCipherSpec – клиент отправляет сообщение Finished, в которой в поле finished_label содержится строка “client finished”, которую сервер должен расшифровать и проверить целостность самого сообщения.

После успешной проверки Finished сообщения от клиента – сервер отправляет своё сообщение ChangeCipherSpec, а затем своё сообщение Finished, в котором в поле finished_label содержится строка “server finished”, которую клиент должен расшифровать и проверить целостность самого сообщения.

В результатах Wireshark – ChangeCipherSpec и зашифрованная строка: