HTTPS 的 RSA 握手过程是建立安全通信通道的核心机制之一。虽然在现代互联网中,为了提供前向安全性(Forward Secrecy) ,基于 Diffie-Hellman(如 ECDHE)的密钥交换算法已逐渐成为主流,但理解经典的 RSA 密钥交换 仍然是掌握 TLS/SSL 原理的基础。
核心概念预备
在开始之前,需要明确几个关键点:
- 非对称加密:用于身份验证和交换"预主密钥"。公钥加密,私钥解密。
- 对称加密:用于后续实际数据传输,效率高。密钥由双方协商生成。
- 数字证书:服务器身份的证明,包含服务器的公钥,由受信任的 CA(证书颁发机构)签名。
- 前向安全性缺失:在纯 RSA 握手中,如果服务器的私钥在未来被泄露,攻击者可以解密过去所有被截获的通信记录(因为预主密钥是用公钥加密传输的)。这是它逐渐被 ECDHE 取代的主要原因。
HTTPS RSA 握手详细步骤解析
假设客户端(浏览器)访问服务器(网站),整个过程通常包含以下 7-8 个主要步骤:
第 1 步:Client Hello(客户端问候)
客户端发起连接,向服务器发送一个 Client Hello 消息。
- 内容包括 :
- 支持的 TLS 版本(如 TLS 1.2)。
- 客户端生成的随机数(Client Random),用于后续生成密钥。
- 支持的加密套件列表(Cipher Suites),例如
TLS_RSA_WITH_AES_128_CBC_SHA。注意这里必须包含RSA关键字。 - 支持的压缩方法。
- (可选)SNI(Server Name Indication),指明要访问的具体域名。
第 2 步:Server Hello(服务器问候)
服务器收到请求后,选择一个双方都支持的配置,回复 Server Hello。
- 内容包括 :
- 选定的 TLS 版本。
- 服务器生成的随机数(Server Random)。
- 选定的加密套件(必须是客户端列表中的,且为 RSA 密钥交换类型)。
- 会话 ID(Session ID),用于会话复用。
第 3 步:Certificate(服务器发送证书)
服务器将自己的 数字证书 发送给客户端。
- 关键点 :证书中包含了服务器的 公钥(Public Key)。
- 客户端会验证证书的有效性(是否过期、是否由可信 CA 签发、域名是否匹配等)。如果验证失败,浏览器会报错拦截。
第 4 步:Server Key Exchange(可选,RSA 握手中通常跳过)
- 注意 :在标准的 RSA 密钥交换 模式中,这一步通常是不需要的。因为服务器的公钥已经包含在证书中了。
- 如果是 DHE 或 ECDHE 模式,服务器会在这一步发送临时的公钥参数。但在纯 RSA 模式下,直接跳到下一步。
第 5 步:Server Hello Done(服务器问候结束)
服务器发送 Server Hello Done 消息,表示初始握手信息已发送完毕,等待客户端响应。
第 6 步:Client Key Exchange(客户端密钥交换)------ 最关键的一步
客户端验证证书无误后,进行以下操作:
- 生成一个 预主密钥(Pre-Master Secret)。这是一个随机数。
- 使用服务器证书中的 公钥 对这个预主密钥进行 RSA 加密。
- 将加密后的数据发送给服务器。
安全原理:只有拥有对应 私钥 的服务器才能解密这段数据,拿到预主密钥。即使中间人截获了数据包,由于没有私钥,也无法解密出预主密钥。
第 7 步:生成会话密钥(双方本地计算)
此时,客户端和服务器都拥有了三个随机数:
- Client Random
- Server Random
- Pre-Master Secret(预主密钥)
双方使用相同的算法,利用这三个随机数独立计算出相同的 主密钥(Master Secret) ,进而衍生出用于实际数据加密的 会话密钥(Session Keys)(包括加密密钥和 MAC 密钥)。
- 注意:会话密钥本身从未在网络上传输过。
第 8 步:Change Cipher Spec & Finished(切换加密与完成)
为了确认密钥生成成功且握手过程未被篡改,双方进行最后的确认:
- Client Change Cipher Spec:客户端通知服务器,"接下来的消息我将用刚才协商好的会话密钥进行加密"。
- Client Finished:客户端发送一条加密消息,包含之前所有握手消息的摘要(Hash)。服务器解密并验证,如果一致,说明握手过程完整且密钥正确。
- Server Change Cipher Spec:服务器通知客户端,"我也开始使用会话密钥加密了"。
- Server Finished:服务器发送加密的验证消息。客户端解密验证。
一旦这两次 Finished 验证通过,握手正式结束。
后续通信
握手完成后,客户端和服务器之间所有的 HTTP 请求和响应数据,都将使用协商好的 对称加密算法(如 AES)和 会话密钥 进行加密传输。对称加密速度快,适合大量数据传输。
总结与现状分析
| 特性 | RSA 握手 | ECDHE 握手 (现代主流) |
|---|---|---|
| 密钥交换方式 | 客户端生成预主密钥,用服务器公钥加密传输 | 双方通过椭圆曲线算法协商生成预主密钥,不直接传输 |
| 前向安全性 | 无。若服务器私钥泄露,历史通信可被解密 | 有。即使私钥泄露,无法推导之前的会话密钥 |
| 性能 | 客户端计算量小,服务器解密消耗较大 | 计算稍复杂,但现代硬件优化良好 |
| TLS 1.3 支持 | 不支持 (已被移除) | 强制要求 (主要支持模式) |
| 当前地位 | 逐渐淘汰,仅用于兼容旧系统或特定内网场景 | 互联网标准配置 |