1. HTTPS密钥交换的数学魔法
第一次接触HTTPS密钥交换时，我也被这个"魔术"惊呆了——两个从未谋面的陌生人，在公开场合下交谈，居然能神不知鬼不觉地商量出一个只有他们知道的秘密。这就像两个特工在拥挤的咖啡馆里，当着所有人的面交换情报，却没人能破解他们的暗号。
1.1 日常生活中的密钥交换
想象这样一个场景：你和朋友Alice想在一个公开的聊天群里约定一个秘密数字，但不想让群里的其他人知道。你们可以这样做：
- 你们先公开约定一个基础数字，比如5
- 你私下选一个秘密数字（比如3），计算5×3=15，然后在群里发"15"
- Alice私下选另一个秘密数字（比如7），计算5×7=35，然后在群里发"35"
- 你收到35后，用自己的秘密数字3计算35×3=105
- Alice收到15后，用自己的秘密数字7计算15×7=105
神奇的事情发生了！你们都得到了105这个相同的数字，而群里的其他人虽然看到了15和35，却无法推算出105。这就是迪菲-赫尔曼密钥交换(Diffie-Hellman)的简化版。
注意：实际HTTPS使用的数学运算要复杂得多，这个例子只是为了便于理解基本原理。
1.2 从简单乘法到复杂数学
现实中HTTPS使用的不是简单的乘法，而是基于离散对数问题的数学运算。具体来说，它使用以下组件：
- 一个大质数p（通常至少2048位）
- 一个生成元g（g的某些幂次模p能生成一个大循环群）
- 双方各自选择私钥：
- 客户端私钥a（随机数）
- 服务器私钥b（随机数）
- 双方计算并交换公钥：
- 客户端公钥A = g^a mod p
- 服务器公钥B = g^b mod p
- 最终双方计算共享密钥：
- 客户端计算s = B^a mod p = (g^b)^a mod p = g^(ab) mod p
- 服务器计算s = A^b mod p = (g^a)^b mod p = g^(ab) mod p
这个过程的精妙之处在于，即使攻击者截获了g、p、A和B，由于离散对数问题的计算复杂度，他们也无法在合理时间内计算出a或b，因此无法得到共享密钥s。
2. TLS握手中的密钥交换实战
2.1 完整的TLS 1.2握手流程
让我们看一个典型的TLS 1.2握手过程：
-
客户端发送ClientHello：
- 支持的TLS版本
- 随机数ClientRandom
- 支持的密码套件列表
- 支持的椭圆曲线（如果使用ECDHE）
-
服务器响应ServerHello：
- 选择的TLS版本
- 随机数ServerRandom
- 选择的密码套件
- 选择的椭圆曲线参数（如果使用ECDHE）
-
服务器发送Certificate消息：
- 包含服务器证书链
-
服务器发送ServerKeyExchange（如果使用DHE/ECDHE）：
- 密钥交换参数（DH参数或EC参数）
- 服务器临时公钥
- 使用服务器私钥对这些参数的签名
-
服务器发送ServerHelloDone
-
客户端发送ClientKeyExchange：
- 客户端临时公钥（基于服务器提供的参数）
-
双方现在可以计算预主密钥：
- 使用各自的私钥和对方的公钥
- 通过DH/ECDHE计算得到相同的预主密钥
-
双方派生主密钥和会话密钥：
- master_secret = PRF(pre_master_secret, "master secret", ClientRandom + ServerRandom)
- 然后派生出加密密钥、MAC密钥等
2.2 椭圆曲线迪菲-赫尔曼(ECDHE)的优势
现代HTTPS更倾向于使用ECDHE而非传统的DH，原因包括：
-
更小的密钥尺寸提供同等安全性：
- 256位ECC ≈ 3072位RSA/DH
- 减少了传输数据量
-
前向安全性：
- 即使服务器长期私钥泄露，过去的会话也不会被解密
- 因为每次握手都使用新的临时密钥对
-
计算效率更高：
- ECC运算比传统DH快得多
- 特别适合移动设备等资源受限环境
3. 密钥交换的安全考量
3.1 中间人攻击的防范
密钥交换协议必须防范中间人攻击(MITM)。HTTPS通过以下机制实现：
-
证书验证：
- 服务器证书由可信CA签发
- 客户端验证证书链和域名匹配
- 检查证书是否被吊销(OCSP/CRL)
-
签名验证：
- ServerKeyExchange消息中的参数由服务器私钥签名
- 客户端用服务器证书中的公钥验证签名
-
Finished消息验证：
- 双方交换的Finished消息包含对之前所有握手消息的MAC
- 确保握手过程未被篡改
3.2 密钥交换算法的选择
不同的密钥交换算法有不同的安全特性：
| 算法 | 前向安全 | 密钥复用 | 计算开销 | 密钥长度 |
|---|---|---|---|---|
| RSA | 否 | 是 | 低 | 2048+ |
| DH | 是 | 否 | 中 | 2048+ |
| ECDH | 是 | 否 | 低 | 256+ |
| ECDHE | 是 | 否 | 低 | 256+ |
最佳实践：现代网站应优先使用ECDHE_RSA或ECDHE_ECDSA密码套件，它们提供了前向安全性。
4. 实际部署中的注意事项
4.1 常见配置错误
在配置HTTPS服务器时，需要注意：
-
避免使用弱密码套件：
- 禁用EXPORT、ANON、NULL、RC4、DES等弱算法
- 优先选择AES-GCM和CHACHA20-POLY1305
-
正确设置证书链：
- 包含所有中间证书
- 避免使用自签名证书（除非内部使用）
-
启用OCSP Stapling：
- 减少客户端验证证书时的延迟
- 提高隐私性（不向CA泄露用户访问信息）
4.2 性能优化技巧
-
会话恢复：
- 使用Session ID或Session Ticket
- 避免每次握手都进行完整的密钥交换
-
TLS False Start：
- 客户端在发送Finished后立即发送应用数据
- 减少一次RTT延迟
-
0-RTT数据（TLS 1.3）：
- 对于重复连接，可以在第一个消息中就发送应用数据
- 但要注意重放攻击风险
5. 从理论到实践：一个密钥交换的完整示例
让我们通过一个具体的例子（使用较小的数字便于理解）来演示ECDHE密钥交换：
-
双方约定使用secp256r1椭圆曲线：
- 曲线方程：y² = x³ - 3x + b (mod p)
- 基点G的坐标(x,y)
-
服务器选择私钥b=10，计算公钥B = 10×G
-
客户端选择私钥a=15，计算公钥A = 15×G
-
双方交换公钥A和B
-
客户端计算共享密钥：a×B = 15×10×G = 150×G
-
服务器计算共享密钥：b×A = 10×15×G = 150×G
-
双方从共享密钥的x坐标派生出实际的加密密钥
在实际中，私钥a和b是256位的随机数，使得通过公钥A或B反推私钥在计算上不可行。
6. TLS 1.3的改进
TLS 1.3对密钥交换做了重大改进：
-
移除了不安全的算法：
- 只保留ECDHE和PSK
- 移除了静态RSA和静态DH
-
简化握手：
- 将密钥交换和认证合并到一个消息中
- 通常只需1-RTT（甚至0-RTT）
-
更安全的密钥派生：
- 使用HKDF进行密钥派生
- 更清晰的密钥分离
-
移除压缩和重协商：
- 消除了相关攻击面
TLS 1.3的密钥交换更加高效和安全，是未来的发展方向。