[!info] related notes

• 所属 MOC: http-and-frontend-networking-moc
• 概念: https
• 断开: https挥手

HTTPS四次握手

在理解 HTTPS 握手之前，我们需要明确一个大前提：HTTPS = HTTP + TLS/SSL。 这意味着，在进行 HTTPS 握手之前，客户端和服务端已经先完成了刚才我们聊过的 TCP 三次握手。在 TCP 连接建立的通道之上，才会开始进行 TLS/SSL 握手，目的是为了协商出一个安全的“对称加密密钥”，用来加密后续真正的 HTTP 业务数据。

我以目前最经典的 TLS 1.2 协议为例，为您拆解这极为精妙的 HTTPS 握手过程（通常包含 4 个核心来回，俗称“四次握手”）：

一、 HTTPS（TLS）的建立握手过程

1. Client Hello（客户端打招呼）

• 动作：客户端向服务端发送一个明文请求。
• 携带内容：支持的最高 TLS 版本、支持的密码套件候选列表（比如 RSA 或 ECDHE）、以及一个非常重要的客户端随机数（Client Random）。

2. Server Hello & Certificate（服务端回应并亮出身份）

• 动作：服务端收到请求后，给客户端回信。
• 携带内容：
  • 确认使用的 TLS 版本和最终决定的一个密码套件。
  • 服务端也生成一个**服务端随机数（Server Random）**发给客户端。
  • 最核心的：下发服务器的数字证书（Certificate）。这个证书里包含了网站的域名、颁发机构（CA），以及服务器的公钥。

3. 客户端验证证书 & 发送 Pre-master Secret（客户端验明正身并生成第三个随机数）

• 动作：客户端收到证书后，会去操作系统的信任根证书库里验证这个证书是不是合法的（查防伪、查过期、查域名匹不匹配）。
• 生成预主密钥：验证通过后，客户端会生成第三个随机数（预主密钥 Pre-master Secret）。
• 加密发送：客户端用刚才证书里的服务器公钥，把这个“预主密钥”加密，发送给服务端。（此时，只有拥有私钥的服务端才能解密出这个随机数，黑客抓包也解不开，这就是非对称加密的妙用）。

4. 生成会话密钥 & 握手结束（Change Cipher Spec & Finished）

• 对称密钥生成：现在，客户端和服务端手里都有了三个材料：客户端随机数 + 服务端随机数 + 预主密钥。双方根据约定好的算法，各自在本地计算出一个完全相同的会话密钥（Master Secret / Session Key）。
• 握手完成：双方各自互相发送一条 Change Cipher Spec 消息（告诉对方：“以后咱们就用这个对称密钥加密聊天了”），并发送一条加密的 Finished 消息（包含前面所有握手数据的摘要，确保中间没被黑客篡改）。

至此，HTTPS 握手完成！ 接下来双方发送的 HTTP 请求（如 GET / POST），都会用这个对称会话密钥进行极速的加密和解密。