📚 课程目录第1章 Cipher Suite 概述

Cipher Suite 概述：定义、历史演化与作用

好，咱们直接进入正题。Cipher Suite 这个词，你查 RFC 文档能翻出一大堆定义，但说白了——它就是一套密码学算法的组合套餐。好比你去快餐店点套餐，主食、配菜、饮料都给你配好了。Cipher Suite 也是一样：密钥交换、身份认证、对称加密、完整性校验，四个组件缺一不可。

一、Cipher Suite 的组成框架

我习惯把 Cipher Suite 拆成四个零件，你看一眼就懂：

核心四要素：
密钥交换算法 – 比如 ECDHE、DHE，负责安全地协商共享密钥
身份认证算法 – 比如 RSA、ECDSA，用于验证服务器/客户端的证书
对称加密算法 – 比如 AES-GCM、ChaCha20，负责真正加密传输数据
消息认证码 (MAC) – 比如 SHA256、POLY1305，确保数据没有被篡改

举个实际例子：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。你把它拆开看：

字段	含义
TLS	协议版本（TLS 1.2/1.3）
ECDHE	密钥交换使用椭圆曲线 Diffie-Hellman 临时密钥
RSA	证书身份认证使用 RSA 签名
WITH	分隔符，纯语法糖
AES_128_GCM	对称加密使用 128 位 AES 伽罗瓦计数模式（AEAD）
SHA256	密钥推导和 MAC 使用 SHA-256 哈希函数

一个小经验： 很多新手会忽略「临时密钥」和「静态密钥」的区别。ECDHE 里的 E 是 Ephemeral，每次握手生成新密钥，就算私钥泄露也解密不了历史会话 — 这叫前向安全性。我在项目里见过有人配了 ECDH（没有 E），结果证书泄露后所有历史通信全部暴露，教训深刻。

二、历史演化：从混乱到精简

Cipher Suite 的演化史其实就是安全攻防的缩影。我刚开始做安全时，SSL 3.0 刚刚被弃用，TLS 1.0 还遍地走。你看看这张表就明白为什么我们拼命移除老套件了：

协议版本	典型套件举例	已知问题
SSL 2.0	SSL_RSA_WITH_RC4_128_MD5	明文填充、弱密钥、无身份验证
SSL 3.0	SSL_RSA_WITH_3DES_EDE_CBC_SHA	POODLE 攻击漏洞
TLS 1.0	TLS_RSA_WITH_AES_128_CBC_SHA	BEAST 攻击、CBC 模式可预测 IV
TLS 1.1	同上（增加显式 IV）	基本相同，只是打补丁
TLS 1.2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	支持 AEAD、改进的密钥派生
TLS 1.3	TLS_AES_128_GCM_SHA256	简化套件、移除所有不安全选项

你注意看，TLS 1.3 的套件名字已经看不到 RSA 和 DH 了，只剩下 AEAD 密码 + 哈希。为什么会这样？因为 IETF 决定把密钥交换和身份认证从套件里抽出去，放到握手协议的扩展里统一管理。我当年刚学 TLS 1.3 时，看到那只有 5 个套件的列表愣了半天——确实清爽太多了。

避坑指南： 我曾经遇到一个客户，直接把 TLS 1.3 套件列表贴到了 Nginx 的 TLS 1.2 配置里，结果全部握手失败。记住：TLS 1.3 的套件格式是 TLS_AES_128_GCM_SHA256，没有中间的 WITH 和 ECDHE 字样。这点很容易踩坑。

三、Cipher Suite 在 TLS 握手中的作用

说白了，Cipher Suite 决定了整个握手流程怎么走。每次建立 TLS 连接，客户端和服务器先交换支持的套件列表，然后选出双方都认同且安全级别最高的那个。我画了一张流程图，展示一次简化的握手过程，重点看 Cipher Suite 出现在哪里：

从图里你能看到，Cipher Suite 在 ClientHello 里被客户端列出，服务端从中选一个最适合的（我一般推荐优先选 ECDHE + AEAD 的套件）。选定后，双方基于这个套件对应的算法完成密钥交换、证书验证，最后用对称密钥加密 Finished 消息。如果 Finished 能解密验证成功，握手才算真正完成。

关键点： 整个握手过程中，Cipher Suite 决定了三个核心逻辑：
用哪种方式交换共享密钥（比如 ECDHE 还是 RSA）
用哪种算法加密数据（比如 AES-GCM 还是 ChaCha20）
用哪种哈希保证完整性（比如 SHA256 还是 SHA384）

你想想看，如果一个套件里用了 CBC 模式又没有 MAC-then-Encrypt 保护，那 BEAST、Lucky13 这些攻击可以直接瘫痪整个连接——这就是为什么我们要禁用弱套件。

四、别忘了 TLS 1.3 的变化

我个人觉得 TLS 1.3 最革命性的改动就是 Cipher Suite 列表被砍到只剩 AEAD 方案。这意味着所有不安全的 CBC、RC4、3DES 都直接出局。而且握手流程也变了——原来需要两次往返（2-RTT），现在 1.3 只需一次往返（1-RTT）就能完成密钥协商。当然，你用的套件必须支持 AEAD，否则 1.3 根本跑不起来。

实战建议： 我目前在服务器上只保留以下三个套件（按优先级排列）：

TLS_AES_128_GCM_SHA256         # 兼容性最好
TLS_AES_256_GCM_SHA384        # 政府/金融场景
TLS_CHACHA20_POLY1305_SHA256  # 移动端/嵌入式

对于 TLS 1.2 兼容，我额外加两个：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

其他？全禁用。这组合能覆盖 99% 的客户端，且没有已知的实用攻击。

五、为什么我们还要讲弱套件？

每次做渗透测试，我总能扫到几个还开着 TLS_RSA_WITH_3DES_EDE_CBC_SHA 的生产环境。明明 3DES 的有效密钥强度只有 112 位，而且 Sweet32 攻击可以让攻击者在几十小时内碰撞出会话密钥。为什么还有人留着？大部分是因为历史债务——旧版 JDK、老版本的 OpenSSL、嵌入式设备定制固件……你想想看，这些系统里如果不上线弱套件，根本连不上。

所以后面的课程，我会手把手教你怎么识别、禁用、替换这些弱套件。咱们要把这些历史包袱一个个拆掉。

这一章就到这里。记住：Cipher Suite 不是 RFC 里那几个冷冰冰的字符串，它是你每一秒安全通信的基石。选对了，事半功倍；选错了，门户大开。