HTTPS 中的 ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)握手是目前互联网最主流的安全连接建立方式。它结合了 椭圆曲线加密(ECC) 的高效性和 临时密钥(Ephemeral) 带来的前向安全性。
一、核心概念:为什么是 ECD
在深入流程前,需要理解两个关键点:
-
ECDH (椭圆曲线迪菲 - 赫尔曼):
- 相比传统的 DH 算法,ECC 可以在更短的密钥长度下提供相同的安全性(例如 256 位 ECC 相当于 3072 位 RSA),计算更快,带宽占用更小。
- 它允许通信双方在不直接传输密钥的情况下,通过交换公开参数,各自独立计算出相同的共享秘密(Shared Secret)。
-
Ephemeral (临时性):
- 这是"前向保密"(Forward Secrecy, PFS)的关键。
- 每次握手时,服务器和客户端都会生成一对临时的公私钥。握手结束后,这些临时私钥立即被销毁。
- 意义:即使攻击者长期窃听并记录了所有流量,且在未来某天破解了服务器的长期私钥(用于签名的那个),他也无法解密过去的会话,因为解密所需的"临时私钥"已经不存在了。
注意:在 ECDHE 握手中,服务器的长期私钥(如 RSA 或 ECDSA 私钥)仅用于数字签名以验证身份,不用于加密会话密钥。这与旧的 RSA 密钥交换机制有本质区别。
二、TLS 1.2 下的 ECDHE 握手全流程(四次握手)
第 1 步:Client Hello(客户端发起)
客户端向服务器发送第一个消息,包含:
- 支持的 TLS 版本(如 TLS 1.2)。
- 客户端随机数 (Client Random):32 字节,用于后续生成会话密钥。
- 支持的加密套件列表:按优先级排列,其中包含 ECDHE 相关的套件。
- 支持的椭圆曲线列表 :如
secp256r1(P-256)。 - Session ID:如果希望恢复之前的会话(会话复用)。
第 2 步:Server Hello + Certificate + Server Key Exchange + Server Hello Done
服务器回应一系列消息(通常合并发送):
-
Server Hello:
- 确认使用的 TLS 版本。
- 服务器随机数 (Server Random):32 字节。
- 选定的加密套件 :确认为
TLS_ECDHE_RSA...。 - 选定的椭圆曲线。
-
Certificate(证书):
- 发送服务器的数字证书(包含服务器的长期公钥,如 RSA 公钥)。
- 客户端将验证证书链、有效期、域名匹配等,以确认服务器身份。
-
Server Key Exchange (关键步骤):
- 服务器生成一对临时的椭圆曲线公私钥。
- 发送 临时公钥 (Server Ephemeral Public Key) 给客户端。
- 数字签名 :服务器使用自己的长期私钥(证书里的私钥)对"客户端随机数 + 服务器随机数 + 临时公钥"进行签名。
- 目的:防止中间人篡改临时公钥。客户端可以用证书里的长期公钥验证这个签名。
-
Server Hello Done:
- 表示服务器初始握手信息发送完毕。
第 3 步:Client Key Exchange + Change Cipher Spec + Finished
客户端收到服务器信息并验证证书和签名后:
-
Client Key Exchange:
- 客户端也生成一对临时的椭圆曲线公私钥。
- 发送 临时公钥 (Client Ephemeral Public Key) 给服务器。
- 密钥计算 :此时,客户端拥有 [服务器临时公钥 + 自己临时私钥],服务器拥有 [客户端临时公钥 + 自己临时私钥]。双方利用 ECDHE 算法,各自独立计算出相同的 Pre-Master Secret (预主密钥)。
- 注意:这里不需要像 RSA 那样用公钥加密预主密钥发送过去,因为预主密钥从未在网络上传输。
-
Change Cipher Spec:
- 通知服务器:"接下来的消息我将使用协商好的密钥和算法进行加密"。
-
Finished:
- 发送第一条加密消息。包含之前所有握手消息的哈希值(校验和),用于验证握手过程是否被篡改。
第 4 步:Change Cipher Spec + Finished(服务器回应)
服务器收到客户端的临时公钥后:
- 密钥计算 :服务器利用 [客户端临时公钥 + 自己临时私钥] 计算出同样的 Pre-Master Secret。
- Change Cipher Spec:通知客户端开始加密通信。
- Finished:发送加密的校验消息,验证握手完整性。
至此,握手完成,双方开始使用对称加密(如 AES)传输业务数据。
三、会话密钥是如何生成的?
在 ECDHE 握手中,最终的对称会话密钥(Session Key)是由三方因素共同生成的,确保每次会话都独一无二:
- Client Random (明文传输)
- Server Random (明文传输)
- Pre-Master Secret (通过 ECDHE 算法本地计算得出,从未传输)
四、RSA 握手 vs ECDHE 握手
| 特性 | RSA 密钥交换 (旧式) | ECDHE 密钥交换 (主流) |
|---|---|---|
| 密钥传递方式 | 客户端生成预主密钥,用服务器公钥加密后发送 | 双方交换临时公钥,本地计算预主密钥 |
| 服务器私钥用途 | 用于解密预主密钥 | 仅用于签名验证身份 |
| 前向保密 (PFS) | 不支持。若私钥泄露,历史流量可被解密 | 支持。临时私钥用完即焚,历史流量安全 |
| 性能 | 解密运算较重 (大数分解) | 椭圆曲线运算快,效率更高 |
| 现状 | 已逐渐被淘汰 (TLS 1.3 已移除) | 当前互联网标准配置 |
总结
HTTPS ECDHE 握手的核心价值在于**"安全"** 与**"效率"**的平衡:
- 安全:通过"临时密钥"实现了前向保密,即使服务器私钥未来泄露,过去的通信依然安全;通过"数字签名"防止了中间人攻击。
- 效率:利用椭圆曲线算法,以更小的计算量实现了高强度的密钥协商。