RSA握手过程

HTTPS 是应⽤层协议，需要先完成 TCP 连接建⽴，然后⾛ TLS 握⼿过程后，才能建⽴信信安全的连接

HTTPS = HTTP + SSL/TLS。 HTTPS 的本质是在 HTTP 协议之上增加了一个安全层，这个安全层最初由 SSL 协议实现，后来演进为更安全的 TLS 协议。
SSL 是 TLS 的前身。 TLS 是 SSL 的标准化、更安全的升级版。SSL 已经因为安全漏洞而被彻底废弃。
出于习惯和兼容性，人们（包括很多开发者）仍然会混用 "SSL" 和 "TLS"，甚至在技术文档中看到 "SSL/TLS" 的写法。但在技术层面，我们应该使用"TLS"。

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。

在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。

好的，我们来详细讲解一下 TLS 四次握手。这其实是 TLS 协议建立安全连接的核心过程，通常被称为 TLS 握手协议。

为了更直观，我们先看一张经典的流程图，然后分步骤拆解：
Server Client Server Client TLS Handshake (Simplified - RSA Key Exchange Example) 验证证书，提取公钥安全连接建立，开始加密通信 ClientHello (Random_C, Cipher Suites, Extensions) ServerHello (Random_S, Selected Cipher Suite) Server Certificate ServerHelloDone ClientKeyExchange (Encrypted Premaster Secret) ChangeCipherSpec Finished (Encrypted) ChangeCipherSpec Finished (Encrypted)

上图展示了最经典的 RSA 密钥交换 流程。下面我们对每一步进行详细解释。

TLS 四次握手详解

"四次握手"指的是在建立 TCP 连接后，为了建立 TLS 安全层，客户端和服务器之间主要进行四轮消息交换（并非严格意义上的4条消息，而是4个来回的数据包组）。

第一阶段：ClientHello

发起方：客户端
目的：向服务器发起加密通信请求，并告知自身的能力和偏好。
主要内容 ：
1. 客户端随机数 (Client Random)：一个由客户端生成的随机数，用于后续生成主密钥。
2. 支持的协议版本：如 TLS 1.2 或 TLS 1.3。
3. 支持的密码套件列表 ：按优先级排列。一个密码套件定义了后续将使用的密钥交换算法 、批量加密算法 和消息认证码算法 。例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。
4. 支持的压缩方法。
5. 会话ID：用于恢复之前的会话（会话恢复）。
6. 扩展字段：如服务器名称指示 (SNI)，用于虚拟主机。

第二阶段：ServerHello + Server Certificate + ServerHelloDone

发起方：服务器
目的：响应客户端，确定通信参数，并证明自己的身份。
包含多条消息 ：
1. ServerHello ：
  - 服务器随机数 (Server Random)：服务器生成的随机数，同样用于后续生成主密钥。
  - 选定的协议版本：从客户端支持的版本中选择。
  - 选定的密码套件：从客户端提供的列表中选择一个。
  - 会话ID：如果支持会话恢复，会提供新的或旧的会话ID。
2. Server Certificate ：
  - 服务器的数字证书。这个证书由受信任的证书颁发机构 (CA) 签发，包含了服务器的公钥、域名等信息。客户端会用预置的 CA 根证书来验证这个证书的合法性，从而确认服务器的身份并获取其公钥。
3. ServerKeyExchange (可选)：如果选定的密码套件需要（例如使用 DHE 或 ECDHE 这种前向安全 的密钥交换算法），服务器会发送自己的临时公钥参数。这是实现前向安全的关键。
4. CertificateRequest (可选)：如果服务器需要验证客户端身份（双向认证），会请求客户端证书。
5. ServerHelloDone ：
  - 通知客户端，服务器这边的初始协商消息已发送完毕。

关键点 ：至此，客户端已经拥有了 Client Random 、Server Random，并通过证书获得了服务器的公钥（或临时公钥参数）。

第三阶段：Client Key Exchange + Change Cipher Spec + Finished

发起方：客户端
目的：进行密钥交换，并切换到加密模式，验证握手过程是否完整和未被篡改。
包含多条消息 ：
1. Client Certificate (可选)：如果服务器要求，客户端发送自己的证书。
2. ClientKeyExchange ：
  - 这是密钥交换的核心。根据之前协商的算法，内容不同：
    - RSA 密钥交换 ：客户端生成一个 预备主密钥 (Premaster Secret) ，并用服务器证书中的公钥加密，发送给服务器。
    - DHE/ECDHE 密钥交换 ：客户端使用服务器传来的参数，生成自己的临时公钥，发送给服务器。双方随后使用迪菲-赫尔曼算法，在不传输 Premaster Secret 的情况下，各自计算出一个相同的 Premaster Secret。
3. CertificateVerify (可选)：如果发送了客户端证书，用私钥签名一段数据，供服务器验证。
4. ChangeCipherSpec ：
  - 一个简单的协议，通知服务器："我后面的消息都要用我们刚协商好的加密算法和密钥来加密了"。
5. Finished ：
  - 这是握手过程中第一条被加密的消息 ！它包含一个特殊的消息认证码 (MAC)，是对之前所有握手消息的摘要，并用刚刚生成的主密钥加密后发送。服务器解密并验证这个 MAC，可以确保整个握手过程没有被篡改（防中间人攻击），且密钥协商正确。

关键点 ：此时，客户端和服务器都拥有了 Client Random 、Server Random 和 Premaster Secret 。双方用这三个参数，通过一个伪随机函数 (PRF) 计算出相同的 主密钥 (Master Secret) 。主密钥再进一步派生出用于实际加密数据的会话密钥（如对称加密密钥、MAC 密钥等）。

第四阶段：Change Cipher Spec + Finished

发起方：服务器
目的：切换到加密模式，并确认握手完成。
包含消息 ：
1. ChangeCipherSpec ：
  - 服务器回应客户端："好的，我也切换到加密模式了"。
2. Finished ：
  - 服务器也发送自己的加密 Finished 消息。客户端对其进行验证。

握手完成

至此，TLS 四次握手全部完成。双方已：

协商了加密算法等参数。
验证了服务器（和/或客户端）的身份。
安全地交换/生成了共享的会话密钥。
确认了握手过程的完整性。

接下来，应用程序数据（HTTP、FTP等）将使用协商好的会话密钥进行加密传输。

重要补充：TLS 1.3 的简化

TLS 1.3 对握手过程做了革命性简化，将传统的"四次握手"减少到了 "一次往返" (1-RTT) ，有时甚至 "零往返" (0-RTT)。核心变化是：

客户端在 ClientHello 中就"猜测"服务器可能支持的密钥交换参数，并发送自己的公钥。
服务器在 ServerHello 中确认参数，并发送证书和自己的公钥，紧接着就可以发送 Finished 消息。
客户端验证后回复 Finished。

这大大提升了连接速度。我们通常说的"四次握手"更多是指 TLS 1.2 及之前的经典模式。

总结

步骤	主要消息	核心目的
第一次	ClientHello	客户端说："我想加密通信，我支持这些算法。"
第二次	ServerHello, Certificate, ServerHelloDone	服务器说："我们用这个算法，这是我的身份证（证书）。"
第三次	ClientKeyExchange, ChangeCipherSpec, Finished	客户端说："这是我的密钥材料，我切换加密了，这是校验码。"
第四次	ChangeCipherSpec, Finished	服务器说："我也切换加密了，这是我的校验码。"

这个过程完美融合了非对称加密 （用于身份认证和密钥交换）和对称加密（用于高效加密应用数据）的优势，并引入了随机数和消息认证来防止重放和篡改攻击，是网络安全通信的基石。

TLS 1.2握手的时间线分析

让我们重新从RTT（往返时间） 角度分析握手过程：

第一轮往返：协商参数

客户端 → 服务器 ：ClientHello
- （开始第一个RTT计时）
服务器 → 客户端 ：ServerHello、Certificate、ServerHelloDone
- （第一个RTT结束）

这不是完整的四次 ，而是第一轮往返。客户端发出Hello，服务器回应。

第二轮往返：密钥交换

客户端 → 服务器 ：ClientKeyExchange、ChangeCipherSpec、Finished
- （开始第二个RTT计时）
服务器 → 客户端 ：ChangeCipherSpec、Finished
- （第二个RTT结束，握手完成）

所以正确的描述是：TLS 1.2握手需要2个完整的RTT。

为什么会有"四次握手"的说法？

术语上的混淆来源：

消息流视角：从消息序列看确实是4条主要消息流
- ClientHello
- ServerHello + Certificate + ServerHelloDone
- ClientKeyExchange + ChangeCipherSpec + Finished
- ChangeCipherSpec + Finished
协议层视角：但物理传输上，第2、3条消息通常在同一数据包中，第4、5条也是
历史原因：早期文献和教学中常用"四次握手"来形象描述这4个关键步骤序列

发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手 (TLS 1.2)的过程，因此共需要 3 个 RTT 的时延才能发出请求数据。

什么是RTT？

RTT（Round Trip Time，往返时延）：数据包从客户端发送到服务器，再返回客户端所需的时间。它是网络延迟的核心度量单位。

一个RTT = 客户端发出请求到收到响应的完整来回时间

HTTPS连接建立的完整过程（3个RTT）

RTT 1️⃣：TCP三次握手（1个RTT）

复制代码

客户端              服务器
  |----- SYN ------>|
  |<---- SYN+ACK ---|  (此时完成1个RTT)
  |----- ACK ------>|

SYN：客户端说"我想连接"
SYN+ACK：服务器说"好的，可以连接"
ACK：客户端说"收到，开始通信"

到这一步，TCP连接建立，耗时1个RTT。

RTT 2️⃣：TLS握手前两轮（1个RTT）

复制代码

客户端              服务器
  |--- ClientHello -->|
  |<-- ServerHello ---|
  |<-- Certificate ---|
  |<-- ServerKeyExchange-|
  |<-- ServerHelloDone -|  (此时完成第2个RTT)
  |--- 后续TLS消息 --->|

ClientHello：客户端支持的TLS版本、加密套件等
ServerHello：服务器选择加密套件、发送证书等

从ClientHello到ServerHelloDone，又耗时1个RTT。

RTT 3️⃣：TLS握手最后交换（1个RTT）

复制代码

客户端              服务器
  |--- ClientKeyExchange->|
  |--- ChangeCipherSpec ->|
  |--- Finished --------->|
  |<-- ChangeCipherSpec --|
  |<-- Finished ----------|  (此时完成第3个RTT)

客户端发送密钥交换信息
双方确认切换到加密通信
验证握手完整性

最后这部分交换，再耗时1个RTT。

可视化时间线

复制代码

时间轴：
0ms     Client        Server
        ├─SYN─────────────►│
        │                  │
        │◄────SYN+ACK──────┤
        │                  │  RTT 1完成 (TCP握手)
        ├─ACK─────────────►│
        │                  │
        ├─ClientHello─────►│
        │                  │
        │◄─ServerHello等───┤  RTT 2完成 (TLS第1轮)
        │                  │
        ├─ClientKeyExchange►│
        │                  │
        │◄─Finished───────┤  RTT 3完成 (TLS第2轮)
        │                  │
        ├─HTTP Request────►│  ★现在可以发送实际数据了！
        │                  │
        │◄─HTTP Response───┤

关键点 ：在TLS 1.2中，必须完成全部3个RTT后，才能发送第一个加密的HTTP请求。