HTTPS RSA 握手解析

HTTPS 的 RSA 握手过程是建立安全通信通道的核心机制之一。虽然在现代互联网中,为了提供前向安全性(Forward Secrecy) ,基于 Diffie-Hellman(如 ECDHE)的密钥交换算法已逐渐成为主流,但理解经典的 RSA 密钥交换 仍然是掌握 TLS/SSL 原理的基础。

核心概念预备

在开始之前,需要明确几个关键点:

  1. 非对称加密:用于身份验证和交换"预主密钥"。公钥加密,私钥解密。
  2. 对称加密:用于后续实际数据传输,效率高。密钥由双方协商生成。
  3. 数字证书:服务器身份的证明,包含服务器的公钥,由受信任的 CA(证书颁发机构)签名。
  4. 前向安全性缺失:在纯 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(客户端密钥交换)------ 最关键的一步

客户端验证证书无误后,进行以下操作:

  1. 生成一个 预主密钥(Pre-Master Secret)。这是一个随机数。
  2. 使用服务器证书中的 公钥 对这个预主密钥进行 RSA 加密
  3. 将加密后的数据发送给服务器。

安全原理:只有拥有对应 私钥 的服务器才能解密这段数据,拿到预主密钥。即使中间人截获了数据包,由于没有私钥,也无法解密出预主密钥。

第 7 步:生成会话密钥(双方本地计算)

此时,客户端和服务器都拥有了三个随机数:

  1. Client Random
  2. Server Random
  3. Pre-Master Secret(预主密钥)

双方使用相同的算法,利用这三个随机数独立计算出相同的 主密钥(Master Secret) ,进而衍生出用于实际数据加密的 会话密钥(Session Keys)(包括加密密钥和 MAC 密钥)。

  • 注意:会话密钥本身从未在网络上传输过。
第 8 步:Change Cipher Spec & Finished(切换加密与完成)

为了确认密钥生成成功且握手过程未被篡改,双方进行最后的确认:

  1. Client Change Cipher Spec:客户端通知服务器,"接下来的消息我将用刚才协商好的会话密钥进行加密"。
  2. Client Finished:客户端发送一条加密消息,包含之前所有握手消息的摘要(Hash)。服务器解密并验证,如果一致,说明握手过程完整且密钥正确。
  3. Server Change Cipher Spec:服务器通知客户端,"我也开始使用会话密钥加密了"。
  4. Server Finished:服务器发送加密的验证消息。客户端解密验证。

一旦这两次 Finished 验证通过,握手正式结束

后续通信

握手完成后,客户端和服务器之间所有的 HTTP 请求和响应数据,都将使用协商好的 对称加密算法(如 AES)和 会话密钥 进行加密传输。对称加密速度快,适合大量数据传输。

总结与现状分析

特性 RSA 握手 ECDHE 握手 (现代主流)
密钥交换方式 客户端生成预主密钥,用服务器公钥加密传输 双方通过椭圆曲线算法协商生成预主密钥,不直接传输
前向安全性 无。若服务器私钥泄露,历史通信可被解密 有。即使私钥泄露,无法推导之前的会话密钥
性能 客户端计算量小,服务器解密消耗较大 计算稍复杂,但现代硬件优化良好
TLS 1.3 支持 不支持 (已被移除) 强制要求 (主要支持模式)
当前地位 逐渐淘汰,仅用于兼容旧系统或特定内网场景 互联网标准配置
相关推荐
测试员周周4 分钟前
【AI测试功能5】AI功能测试的“黄金数据集“构建指南:从0到1搭建质量评估体系
运维·服务器·开发语言·人工智能·python·功能测试·集成测试
treesforest18 分钟前
IP地理位置精准查询:从城市级到街道级的定位技术深度解析
大数据·网络·网络协议·tcp/ip·安全·网络安全·ip
小娄~~1 小时前
进程间通信
linux·运维·服务器
企业网盘服务谷雨网络2 小时前
自建服务器还是云存储?企业存储选型没有标准答案
服务器·数据安全·云存储·企业云盘·企业资产
祁_z2 小时前
LangSmith 实操指南「Agent 可观测性系统」
java·服务器
实心儿儿2 小时前
Linux —— 库的制作和原理(2)
linux·运维·服务器
运维全栈笔记2 小时前
Docker一键部署Immich:自建私有云相册,照片视频备份无忧
linux·服务器·网络·docker·容器
yyuuuzz2 小时前
企业出海中的技术稳定性问题梳理
运维·服务器·网络·github·aws
哼?~2 小时前
再谈UDP协议
网络·网络协议·udp
IPHWT 零软网络2 小时前
OM200G-A融合通信IP-PBX:国产化架构下的高可靠政企通信解决方案
网络协议·tcp/ip·架构