📚 课程目录第3章常见密码套件类型

第三章：常见密码套件类型——RSA、DHE、ECDHE、AES-GCM、ChaCha20-Poly1305

密码套件这东西，说白了就是一堆算法的组合拳。我刚开始做安全测试那会儿，看到TLS握手日志里一串像 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这样的名字，脑袋都大。后来拆开看才发现，其实就四个部分：密钥交换、身份验证、对称加密、消息认证码（MAC）。

你想想看，每次握手都要确定“怎么换钥匙”“怎么证明你是谁”“怎么加密数据”“怎么保证数据没被改”。能用的算法很多，但选错了就是灾难。这一章我们就把最常见的几类掰开揉碎讲清楚。

3.1 密钥交换算法：RSA、DHE、ECDHE

密钥交换解决的是“客户端和服务端怎么安全地商量出一个共同的对称密钥”。三种主流方式，各有各的脾气。

3.1.1 RSA密钥交换

RSA 是最老牌的方案。客户端用服务器证书里的公钥加密一个随机数（pre-master secret），服务器用私钥解密。

优点：实现简单，兼容性极好。
缺点：没有前向安全性。一旦私钥泄露，所有历史会话都能被解密。

⚠ 注意：我曾经在审计一个金融系统时发现，对方仍然使用了 RSA 密钥交换的套件，理由竟然是“以前一直这么用”。我建议立即禁用，否则一旦服务器证书私钥被窃，过去几年的交易记录全都能被还原。RSA 密钥交换现在已经被 TLS 1.3 彻底移除。

3.1.2 DHE（基于离散对数的临时 Diffie-Hellman）

DHE 每次握手都生成全新的 Diffie-Hellman 参数，服务器签名但不直接传递密钥。

优点：提供前向安全性。即使长期私钥泄露，也不会暴露之前会话的密钥。
缺点：性能开销大，参数生成和模幂运算很慢。

我在项目中遇到过一些老旧客户端不支持 ECDHE，只能回退到 DHE。那性能差距真的明显——同样 TLS 握手，DHE 要比 ECDHE 慢 3-4 倍。

3.1.3 ECDHE（椭圆曲线 Diffie-Hellman Ephemeral）

ECDHE 用椭圆曲线代替传统整数群，参数更短，计算更快。目前最推荐的密钥交换方式。

优点：前向安全 + 高性能 + 密钥短。
缺点：需要客户端和服务端都支持相同的曲线（常用 P-256、X25519）。

  🔑 个人习惯：我现在的所有项目都只启用 ECDHE 进行密钥交换，配合 Ed25519 或 ECDSA 做签名，性能和安全都兼顾。TLS 1.3 默认就用 ECDHE，几乎没得选。

3.2 对称加密算法：AES-GCM 与 ChaCha20-Poly1305

钥匙换好之后，真正的数据传输就靠对称加密了。这里两个主角：AES-GCM 和 ChaCha20-Poly1305。它们都是 AEAD（认证加密关联数据）模式——加密的同时完成完整性校验，省掉额外的 MAC 步骤。

主要 AEAD 对称加密对比
算法	加密方式	性能特点	硬件支持	常见场景
AES-GCM	CTR 模式 + GMAC	有硬件加速时极快	主流 CPU 均有 AES-NI	服务器端、移动端（带硬加速）
ChaCha20-Poly1305	流密码 + Poly1305	软件实现效率高，无硬件依赖	少数 ARM 芯片有指令集	移动端、嵌入式、物联网

3.2.1 AES-GCM

AES-GCM 是当前最主流的对称加密方式。如果 CPU 支持 AES-NI 指令集，加解密速度能跑到几十 Gbps。

💡 建议：你可以在服务器端使用 openssl speed -evp aes-128-gcm 测试实际硬件加速能力。我曾在老旧 Xeon 上测过，没 AES-NI 时慢到让人崩溃。

不过有个坑：AES-GCM 对 IV（初始向量）使用非常敏感。IV 必须唯一，如果重复使用了相同的 IV，攻击者可以直接通过 XOR 破解密文，甚至能伪造认证标签。

3.2.2 ChaCha20-Poly1305

ChaCha20 是流密码，由 Daniel J. Bernstein 设计。Poly1305 是配套的认证器。它的优势在于：不需要硬件加速，纯软件实现就能跑得很顺；没有 AES 的IV 重用问题（但每次密钥+Nonce 组合也必须唯一）。

我记得有一次帮一个 IoT 项目选套件，设备用的是 ARM Cortex-M3，根本没有 AES 硬件加速。上 ChaCha20-Poly1305 之后，握手速度提升了 60%。

  🔒 安全建议：如果客户端和服务端都支持，优先选 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 或 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。两个都是强加密切换，主要看你的硬件环境。

3.3 密码套件结构总览

下面这张图帮你理清一个完整密码套件的四个组件是怎么协同工作的。

3.4 常见套件组合速查表

实际部署时，你不可能把所有套件都开着。下面是我个人筛选的“黄金组合”，兼顾安全与兼容性。

推荐密码套件组合
套件标识	密钥交换	认证	加密	MAC	推荐等级
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	ECDHE	ECDSA	AES-128-GCM	AEAD	⭐⭐⭐⭐⭐
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE	RSA	AES-128-GCM	AEAD	⭐⭐⭐⭐⭐
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256	ECDHE	ECDSA	ChaCha20-Poly1305	AEAD	⭐⭐⭐⭐⭐
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	DHE	RSA	AES-128-GCM	AEAD	⭐⭐⭐⭐
TLS_RSA_WITH_AES_128_GCM_SHA256（避免使用）	RSA	RSA	AES-128-GCM	AEAD	⚠️ 不推荐

🚫 避坑指南：我曾经在处理一起漏洞应急时发现，攻击者利用服务端仍然支持 TLS_RSA_WITH_AES_128_CBC_SHA 这个套件，结合 Lucky13 攻击（针对CBC模式的 padding oracle 攻击）窃取了会话密钥。所以，凡是用 CBC 模式的对称算法、以及 RSA 密钥交换的套件，请一律禁用。

3.5 密码套件选择决策要点

前向安全性优先：只选 ECDHE 或 DHE，禁用静态 RSA/DH。
对称加密首选 AEAD：AES-GCM（有硬加速）或 ChaCha20-Poly1305（无硬加速）。
避免 CBC 模式：Lucky13、POODLE 等都是 CBC 模式的老问题。
认证算法看证书类型：RSA 证书用 ECDHE_RSA，EC 证书用 ECDHE_ECDSA。
优先级排序：ECDHE + ECDSA/Ed25519 > ECDHE + RSA > DHE + RSA。

最后说一句：别小看套件排序。服务端配置的套件顺序决定了优先选哪个。我把最强最安全的放前面，老旧弱的放最后甚至直接删掉。客户端再怎么降级，只要服务端不配合，攻击者就没辙。