3. 密码套件（Cipher Suite）概念：结构、字段与含义
说到密码套件，我第一反应就是：它其实是TLS握手的“加密配置单”。每次客户端和服务器打招呼，第一件事就是协商用哪一套算法组合。你看抓包里的Client Hello，里面长长一串Cipher Suite列表，每个都是一个16进制数——嗯，拆开来看，每个数背后都藏着一套完整的密码学工具链。
3.1 Cipher Suite 长什么样？
咱们先看一个真实例子。我随便抓了个TLS 1.2的包，里面有个常见的套件：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。这个字符串就是密码套件的“身份证”。它用下划线分隔成四个部分：协议前缀、密钥交换算法、认证算法、加上加密套件。但你别看它短，它能定死整个安全链路。
说白了，一个密码套件定义了三次握手里要用哪几把钥匙、怎么验证身份、数据怎么加密、完整性怎么保证。我习惯把密码套件看成一张“四合一”合同：双方签字前，先敲定这四个角色。
3.2 密码套件的内部结构
按照TLS RFC 5246（及后续更新），一个完整的密码套件包含下列五个核心字段。我用个表格对比一下，这样你一眼就能看明白每个字段到底负责什么：
| 字段 | 长度（位） | 作用 | 常用算法举例 |
|---|---|---|---|
| 密钥交换算法 | 2字节（TLS ID） | 安全协商共享密钥 | ECDHE、DHE、RSA、PSK |
| 签名/认证算法 | 2字节（有时合并） | 验证对端身份 | RSA、ECDSA、DSS |
| 对称加密算法 | 2字节（含模式） | 加密应用数据 | AES-GCM、AES-CBC、ChaCha20-Poly1305 |
| 消息认证码（MAC） | / | 检篡改、保完整性 | HMAC-SHA256、Poly1305（AEAD内建） |
| 伪随机函数（PRF） | / | 派生密钥材料 | SHA256、SHA384 |
注意：如果你看到套件里带「AEAD」（比如AES_128_GCM），那它已经把加密和MAC合并成一步了。这时候不会有单独的MAC字段——算是现代套件的一个“去重”优化。
3.3 逐字段拆解：我踩过的坑
3.3.1 密钥交换算法
这是握手最核心的一步。你想啊，双方在没有预先约定密钥的情况下，怎么安全地算出同一个共享密钥？常见的有：
- DHE（临时Diffie-Hellman）：提供PFS（完美前向保密）。不过握手需要交换两个大数，延迟略高。
- ECDHE（椭圆曲线Diffie-Hellman）：用更短的密钥达到同样安全级别，现在几乎每种现代浏览器都支持。我在项目中遇到过一个坑：某设备只支持P-256曲线，而服务端只配了X25519，结果一直握手失败。所以选曲线时一定要双方对齐。
- RSA（静态密钥交换）：老套件，不提供PFS。客户端用服务器公钥加密一个随机数，服务器再解密。一旦私钥泄露，之前所有会话都能被解密。我现在见到熊套件会直接禁用。
3.3.2 签名/认证算法
服务器需要证明“我确实拥有刚才密钥交换里用的证书对应的私钥”。常见签名算法：RSA、ECDSA、EdDSA。我记得有一次调试一个HTTPS接口，客户端报证书校验失败，抓包发现签名算法写的是MD5withRSA——这玩意儿早就不安全了。浏览器根本不认。
我曾经帮一个客户排查问题，他们内部OA用的TLS 1.0，套件是TLS_RSA_WITH_RC4_128_SHA。这简直是把所有安全短板集齐了：无PFS + 流密码RC4（已破解）+ SHA-1（已过时）。建议你们在服务器上彻底禁用这种套件，除非你是在模拟古老的攻击实验。
3.3.3 对称加密算法
握手结束后，真正的应用数据就用这个算法加解密。现在的黄金标准是AES-GCM和ChaCha20-Poly1305。GCM是CTR模式加GMAC认证，软硬件都支持得很好。ChaCha20在移动端没AES硬件加速时表现更好。我个人的习惯是：优先TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256给笔记本，客户端用TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256给手机。
3.3.4 消息认证码（MAC）
在非AEAD套件里，MAC用于检测数据有没有被篡改。它和加密是两码事：先加密，再计算MAC（或者反过来）。TLS 1.2之前的CBC模式常被攻击（比如padding oracle），就是因为加密和MAC的顺序没处理好。而AEAD套件直接内置认证标签，避免了这个麻烦。
你问：那我到底该用AEAD还是老套件？说白了，只要客户端和服务器都支持，无脑选AEAD。我最近检查过的生产环境，几乎已经没有非AEAD套件在用了。
3.3.5 伪随机函数（PRF）
PRF负责把握手阶段算出的“预主密钥”扩展开，生成一堆具体的密钥材料：加密密钥、IV、MAC密钥等等。TLS 1.2用SHA-256作为默认PRF（部分套件用SHA-384）。TLS 1.3直接固定为HKDF，算法更简洁也更安全。
你想想看，客户端和服务器协商完主密钥后，需要同时为进站和出站方向各生成一套密钥。PRF就像一台配方机器，输入一个主密钥和会话ID，输出几个独立的长密钥——这样就不会出现双向用同一个密钥的情况。
3.4 密码套件整体流程（SVG）
我把整个密码套件在握手过程中的角色画成了一张图，方便你理解每个字段的协作关系：
3.5 一些实战建议
最后说说我自己的习惯。当你配置服务器时，密码套件的顺序极其重要。浏览器会把服务端返回的第一条可用套件当作首选。所以别用默认顺序——把 ECDHE + AEAD + PFS 的套件放前面，把使用静态RSA或CBC模式的老套件放末尾甚至删掉。我曾经在Nginx上只保留4个套件，性能没有任何下降，反而通过了所有安全扫描。
一个小技巧：用openssl命令查看当前支持的套件列表，然后手工修剪。命令：openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20'。多跑几次，你会发现很多冗余项。
好了，以上就是密码套件里五个核心字段的拆解。每次握手，TLS就是在这些盒子里各选一个，拼出一个完整的加密方案。下回你再看抓包中的那一串ID，应该不会再觉得它只是一堆乱码了吧？