3、对称加密与非对称加密在TLS中的应用
你有没有想过一个问题——TLS 握手，为什么非得搞两套加密体系？
我刚开始接触 HTTPS 调优时，也觉得奇怪。对称加密又快又好，干嘛要多套一层非对称？直到我在项目里真正抓了一次握手包，才明白这背后的设计有多聪明。
说白了，对称加密管的是“快”，非对称加密管的是“安全分发”。两者凑在一起，才撑起了 TLS 的加密传输。
3.1 为什么需要两种加密？
先看一组对比。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 一个密钥 | 公钥 + 私钥 |
| 速度 | 极快（硬件加速常见） | 慢（比对称慢 1000 倍以上） |
| 密钥分发 | 需要安全信道 | 公钥公开即可 |
| TLS 中的角色 | 加密传输数据 | 交换对称密钥、身份认证 |
你看，对称加密负责“干活”，非对称加密负责“开门”。
如果只用对称加密，那双方怎么安全地拿到同一个密钥？反过来，如果全程非对称加密，服务器光解密一个请求就慢了，用户可受不了。
这就是混合加密体系。 我习惯管它叫“分工合作模式”。
3.2 对称加密在 TLS 中的实际位置
握手完成后，客户端和服务端就已经拥有了相同的“会话密钥”。这个密钥是怎么来的？我们后面会详细拆解密钥协商。但是它的用途很简单：加密握手后的应用数据。
常见的对称算法有 AES、ChaCha20。你可以在密码套件里指定哪种。
举个例子。如果你配置了 TLS_AES_128_GCM_SHA256：
1. 握手阶段协商出 128 位 AES 密钥
2. 每条记录都使用 GCM 模式加密
3. 加密同时提供完整性校验（AEAD）我在项目中遇到过 一个真实场景：某老旧设备只支持 CBC 模式，不支持 GCM。结果流量一大，性能瓶颈就出来了。后来换了硬件，才平滑迁移到 GCM。所以，如果你是管理员，建议优先启用 GCM 套件。
3.3 非对称加密在 TLS 中的关键战点
非对称加密在 TLS 里主要干两件事：密钥交换 和 数字签名。
- 密钥交换：用 RSA 或 DH 系列算法，安全地传递一个预主密钥，然后双方各自推导出对称密钥。
- 数字签名：服务器用自己的私钥签名证书或握手参数，客户端用公钥验证身份。
RSA 密钥交换是早期最常用的方式。但有个致命弱点：一旦 RSA 私钥泄露，过去的所有通信记录都能被解密。
这就是为什么现在大家都推荐 ECDHE。它提供前向安全性——就算私钥丢了，以前密文也解不了。
我印象很深的一个案例：
3.4 混合加密在 TLS 中的完整流程
下面这张图，展示了我个人最喜欢的理解方式。
它把 TLS 握手流程浓缩成了三个阶段。
三个步骤走下来，你就明白了：非对称管“安全协商”，对称管“高效传输”。缺一不可。
3.5 算法选择与避坑指南
我个人推荐的底线搭配是这样的：
- 密钥交换：ECDHE（优先 X25519，其次 P-256）
- 签名算法：ECDSA 或 Ed25519，别再开 RSA 2048 签名了
- 对称加密：AES-128-GCM 或 ChaCha20-Poly1305
为什么不推荐 AES-256？你想想看，128 位密钥的 AES 在可预见的未来足够安全。用 256 位反而会多消耗 CPU 周期，移动设备尤其吃亏。
TLS_AES_128_GCM_SHA256 和 TLS_CHACHA20_POLY1305_SHA256 放在最前面。这两个套件是目前性能和安全的平衡点。
我曾经在某个 CDN 项目中做过压测。 发现 ChaCha20 在缺少 AES 硬件加速的 ARM 芯片上，速度比 AES-128-GCM 快 30% 以上。所以如果你的用户有很多旧手机，ChaCha20 是需要保留的选项。
3.6 小结
对称加密与非对称加密，在 TLS 里不是二选一的关系。它们是搭档。
非对称加密负责握手中的“信任建立”和“密钥分发”。对称加密负责数据通道的“快速加密”。混合之后，攻击者既拿不到共享密钥（因为非对称的保护），又无法暴力破解每条记录（因为对称加密的轮次太多）。
嗯，说到这，我再提醒一句：不要轻易禁用 ECDHE。有些默认配置会开启 RSA 密钥交换作为兜底，比如 TLS_RSA_WITH_AES_128_GCM_SHA256。这其实是个隐患——没有前向安全。建议直接移除所有不以 ECDHE 或 DHE 开头的套件。