1、TLS协议握手#

标准TLS会话握手过程包含如下5个阶段：

1. ClientHello：客户端发送支持的加密算法列表。
2. ServerHello：服务器选择加密算法并发送服务器证书。
3. 证书验证：客户端验证服务器证书的有效性。
4. 密钥交换：客户端生成预主密钥，用服务器公钥加密后发送。
5. 会话密钥：双方根据预主密钥生成会话密钥，用于加密后续通信。

按照版本不同分别展示如下：

逐字节解析整个连接过程: The Illustrated TLS Connection: Every Byte Explained

TLS 1.2 完整握手（Full Handshake）流程图

1
Client                          Server
2
  |                               |
3
  |--- ClientHello -------------->|   (1) 支持的TLS版本、加密套件、随机数
4
  |<-- ServerHello ---------------|   (2) 选定参数、服务器随机数
5
  |<-- Certificate ---------------|   (3) 服务器证书
6
  |<-- ServerKeyExchange -------->|   (4) 若使用DHE/ECDHE，发送临时公钥
7
  |<-- ServerHelloDone ---------->|   (5) 服务器握手消息结束
8
  |--- ClientKeyExchange -------->|   (6) 客户端发送预主密钥（或临时公钥）
9
  |--- [ChangeCipherSpec] ------->|   (7) 切换到加密模式
10
  |--- Finished ----------------->|   (8) 验证握手完整性
11
  |<-- [ChangeCipherSpec] --------|   (9) 服务器切换加密
12
  |<-- Finished ------------------|   (10) 服务器验证完成
13
  |                               |
14
  |<==> Application Data <=======>|   (11) 加密通信开始

TLS 1.3 完整握手（1-RTT）流程图

1
Client                          Server
2
  |                               |
3
  |--- ClientHello -------------->|   (1) 包含客户端密钥共享（如 ECDH 公钥）、
4
  |                               |       支持的协议、加密套件、随机数
5
  |<-- ServerHello ---------------|   (2) 选定参数 + 服务器密钥共享
6
  |<-- Certificate ---------------|   (3) 服务器证书（可选）
7
  |<-- CertificateVerify -------->|   (4) 证书签名验证（证明私钥持有）
8
  |<-- Finished ------------------|   (5) 服务器完成握手（使用握手密钥加密）
9
  |--- [Finished] --------------->|   (6) 客户端完成（同样加密）
10
  |                               |
11
  |<==> Application Data <======>|   (7) 加密应用数据（使用新派生的密钥）

其中TLS1.3主要简化了流程将标准2-RTT减小到1-RTT甚至复用下0-RTT

2、TLS握手原理概述#

简要概括客户端在建立 TLS 加密过程中主要的工作如下：

1. 协商安全参数客户端通过 ClientHello 消息向服务器表明自身支持的 TLS 版本、加密套件（如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）、压缩方法以及两个关键随机数（Client Random）。这些信息为后续密钥派生和算法选择奠定基础。

2. 验证服务器身份客户端收到服务器证书后，会执行以下验证：

   • 证书是否由受信任的 CA（证书颁发机构）签发；
   • 证书是否在有效期内；
   • 证书中的域名是否与当前访问的主机名匹配（如 SNI 中指定的 example.com）；
   • 证书链是否完整且可追溯至根 CA。 若任一验证失败，连接将被中止（浏览器通常会弹出警告）。

3. 参与密钥协商根据协商的密钥交换算法（如 RSA、ECDHE），客户端执行相应操作：

   • RSA 模式：生成一个 48 字节的预主密钥（Pre-Master Secret）(2位固定+46位随机生成的)，用服务器证书中的公钥加密后发送；
   • (EC)DHE 模式：生成临时的 (EC)DH 密钥对，将临时公钥发送给服务器，并利用对方的临时公钥与自己的私钥计算出共享秘密（即预主密钥）。

   现代 TLS（尤其是 TLS 1.3）强制使用 (EC)DHE，以实现前向保密（Forward Secrecy）。

4. 派生会话密钥客户端使用预主密钥、Client Random 和 Server Random，通过 PRF（伪随机函数，如 HMAC-SHA256）依次派生出：

   • Master Secret（主密钥）
   • 多个会话密钥（包括客户端/服务器的加密密钥、MAC 密钥、IV 等） 这些密钥将用于后续对称加密通信（如 AES-GCM）。

5. 完成握手并验证完整性客户端发送 Finished 消息，该消息包含对整个握手过程所有消息的哈希值，并使用刚生成的会话密钥进行加密和认证。服务器若能正确解密并验证该消息，则证明双方拥有相同的密钥且握手未被篡改。

6. 切换至加密通信 自 ChangeCipherSpec 之后，所有应用层数据（如 HTTP 请求）均使用协商好的对称加密算法和会话密钥进行加密封装，确保机密性、完整性与身份可信。

整个过程在 TLS 1.3 中被大幅优化：密钥交换与身份认证合并，握手消息加密，且仅需 1 个 RTT 即可开始传输应用数据，显著提升性能与隐私。 预主密钥在client和server端都会生成且由于相互公私钥交换，各自生成的预主密钥是一致的

在此基础上，主密钥=PRF(预主密钥, str(“main secret”), client_random||server_random)，生成一直的主密钥后，通过同样PRF生成对应的诸如client_write_secret，server_write_secret等，用于实际的加密解密，此时采用的已经是对称加密。

预主密钥、主密钥等并不会通过网络传输，切记

note: 双随机数是为了避免中间人重放攻击，client和server独立write密钥是为了区分消息主体