From: What happens in a TLS handshake? | SSL handshake | Cloudflare

TLS 1.2

TLS 1.2 采用四次握手的方式来实现：

  1. ClientHello
    客户端首先向服务器发送ClientHello消息，包含客户端支持的 TLS 版本、加密套件列表、压缩方法、以及一个客户端生成的随机数（Client Random）。这个消息还可以包含会话ID，用于会话恢复。
  2. ServerHello
    服务器响应：服务器接收到 ClientHello 后，选择一个共同支持的 TLS 版本和一个加密套件，并生成一个服务器随机数（Server Random）。然后，服务器向客户端发送 ServerHello 消息，包含这些信息。
    证书：服务器接着发送其数字证书，该证书中包含了服务器的公钥。这是用于后续的密钥交换和服务器身份验证的关键。
    密钥交换：如果所选加密套件需要，服务器还将发送一个 ServerKeyExchange 消息，包含密钥交换所需的额外数据。
    客户端证书请求：如果需要客户端认证，服务器将发送 CertificateRequest 消息，要求客户端也提供其证书。
  3. Client Response
    客户端证书：如果服务器请求，则客户端发送其数字证书。
    密钥交换：客户端发送 ClientKeyExchange 消息，通常包含使用服务器公钥加密的预主密钥（Pre-Master Secret）。
    证书验证：如果客户端发送了证书，接下来发送 CertificateVerify消息，以数字签名方式验证客户端证书的有效性。
    更改密码规范：客户端发送 ChangeCipherSpec 消息，通知服务器即将开始加密消息。
    完成消息：客户端发送 Finished 消息，经过加密，包含至此为止所有握手消息的校验和。
  4. Finish Handshake
    更改密码规范：服务器回应一个 ChangeCipherSpec 消息，表明它也将开始加密消息。
    完成消息：服务器发送 Finished 消息，同样经过加密，包含对之前握手消息的验证。

TLS 1.3

TLS 1.3 不仅简化了握手过程，同时更改了加密算法以及消息流等。

1. 减少的握手往返次数

  • TLS 1.3 减少了握手的往返次数（RTT）。在最优配置下，只需要一次往返即可完成握手，称为“1-RTT”握手。相比之下，TLS 1.2 需要两次往返。
  • TLS 1.3 还支持“0-RTT”模式，允许客户端在握手的同时发送加密数据，进一步减少延迟。这种模式适用于重新连接的场景，但需要注意重放攻击的风险。

2. 简化的消息流

  • 在 TLS 1.2 中，握手涉及多个步骤和消息类型，如 ServerKeyExchange、ClientKeyExchange、CertificateVerify 等。TLS 1.3 将这些步骤整合到更少的消息中。
  • TLS 1.3 主要包括 ClientHello、ServerHello、EncryptedExtensions、Certificate、CertificateVerify 和 Finished 消息。

3. 密钥协商和握手密钥简化

  • TLS 1.3 移除了对 RSA 加密密钥交换的支持。所有的密钥协商都必须使用 Diffie-Hellman（DH）或椭圆曲线 Diffie-Hellman（ECDH）。
  • 握手期间使用的密钥和数据加密使用的密钥是分开的，握手完成后，会基于握手密钥派生出应用数据密钥。

4. 统一的密钥派生过程

  • TLS 1.3 使用单一的密钥派生函数 HKDF，并基于此进行所有密钥的生成。相比 TLS 1.2 使用的多种基于 HMAC 的派生方法，TLS 1.3 的方法更为统一和安全。

5. 弃用旧的和不安全的特性

  • TLS 1.3 移除了许多在旧版本中被认为不安全或已过时的加密套件和特性，如静态 RSA 密钥交换、CBC 模式加密和压缩方法等。

6. 改进的安全性和隐私保护

  • 所有握手消息在 ServerHello 之后都是加密的，包括证书消息。这改善了隐私保护，因为中间者无法看到交换的证书或任何其他加密参数。

ECDH：

ECDH 密钥交换 |面向开发人员的实用密码学 (nakov.com)

Cherish those who deserve it.