Cipher Suite 组成要素：四块基石，少一块都不行

大家好，欢迎来到第三章。

上一章我们聊了 Cipher Suite 到底是什么——就是那串看起来乱糟糟的字符串。今天咱们把它拆开，看看里面到底装了些什么。说白了，一个 Cipher Suite 由四部分组成：认证算法、密钥交换算法、对称加密算法、哈希算法。这四块缺一不可，就像汽车的四个轮子。

我个人习惯把这四个要素比作一场加密通信的「四方会谈」：

• 认证：验证对方是不是本人（别被假冒的骗了）
• 密钥交换：如何安全地把钥匙交给对方
• 对称加密：真正加密数据的那道锁
• 哈希：确保数据没被篡改的「指纹」

下面我一个一个讲，每个都带上我踩过的坑，你们少走弯路。

认证算法：你是谁？先亮身份证

认证算法解决的是身份问题。你想想看，如果对方是个冒牌货，你再怎么加密也没用——数据直接交给坏人了。

常见的认证算法有 RSA、ECDSA、EdDSA。它们通常跟数字证书绑在一起。服务器把证书丢过来，客户端用 CA 的公钥验证签名。通过之后，我才信你。

我记得有一次做安全审计，发现某网站虽然用了 ECDHE 密钥交换，但证书签名算法还是 SHA1-RSA。嗯，SHA1 已经不安全了。我立刻建议他们把证书换成 SHA256-RSA 或 ECDSA。这些小细节，攻击者最喜欢钻空子。

密钥交换算法：钥匙怎么安全地给出去？

认证完了，接下来是关键一步——双方得商量一把对称密钥。这个商量过程就是密钥交换算法。

早年主要是 RSA 密钥交换：客户端生成预主密钥，用服务器的 RSA 公钥加密发过去。简单粗暴，但有个致命缺陷——它不提供前向安全性。如果服务器私钥泄露，之前所有通信记录都能被解密。我在项目中遇到过这事，客户的老系统还在用 RSA key exchange，直接被我标记为高危。

现在主流是 Diffie-Hellman (DH) 系列，尤其是 ECDHE（椭圆曲线 Diffie-Hellman 临时模式）。ECDHE 每次握手生成临时密钥对，即使长期私钥泄露，以前的会话也安全。这叫做前向安全性。

主流密钥交换算法对比

算法	前向安全性	性能	当前建议
RSA key exchange	❌ 不支持	快 (但风险高)	💀 禁用
DHE (传统DH)	✅ 支持	慢 (大素数)	🔍 慎用
ECDHE	✅ 支持	快	👍 首选

对称加密算法：锁和钥匙

密钥交换搞定之后，双方都有了一把对称密钥。接下来就靠对称加密算法来保护真正的数据了。

常见的对称加密算法包括 AES（高级加密标准）、ChaCha20、3DES、RC4 等。嗯，3DES 和 RC4 已经过时了，千万别用。

现在主流是 AES-GCM 和 ChaCha20-Poly1305。为什么是它们？因为这是认证加密模式——同时提供加密和完整性校验。AES-GCM 在硬件支持好的设备上快得飞起，ChaCha20 则在手机等 ARM 设备上表现更好。

另外，还要注意密钥长度。AES-128 目前够用，AES-256 更保险。但别盲目上 256，有些场景下 128 更快，安全性差异对于绝大多数场景可以忽略。

哈希算法：它是一枚指纹

哈希算法在这里有两个角色：

• 完整性校验：确保数据在传输过程中没被篡改
• HMAC (哈希消息认证码)：结合密钥，验证消息的真实性

常见的哈希算法有 SHA-256、SHA-384、SHA-512，还有旧的不安全的 MD5 和 SHA-1。

在 Cipher Suite 里，哈希算法会参与生成消息认证码 (MAC)。有些套件写的是 SHA256，代表用 HMAC-SHA256 做完整性校验。

哈希算法安全等级

算法	安全性	当前建议
MD5	💀 极低	禁用
SHA-1	⚠️ 低	不建议使用
SHA-256	✅ 高	推荐
SHA-384/SHA-512	✅ 很高	高安全性场景

如何把这四个要素组合起来？

好了，现在你知道了四个要素各自的作用。但实际配置里，它们是以一个整体出现的。比如：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

拆开看就是：

• 密钥交换：ECDHE（临时椭圆曲线DH）
• 认证：RSA（用RSA证书签名）
• 对称加密：AES-256-GCM
• 哈希：SHA-384（用于PRF和HMAC）

是不是清晰多了？