4. 加密套件（Cipher Suite）的概念与选择
咱们正式进入第四个关键话题——加密套件。
说白了，加密套件就是 TLS 握手时，客户端和服务端商量好的一套“加密方案”。它决定了用什么算法来交换密钥、用什么算法来认证身份、数据怎么加密、完整性怎么校验。
我之前带过几个新人，他们看到抓包里的 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 直接懵了。说实话，我刚入行那会儿也懵，这串字符太长了吧？
别怕，拆开来看，其实就四个部分。
4.1 加密套件的组成结构
一个完整的加密套件，格式通常是这样的：
TLS_密钥交换算法_认证算法_WITH_加密算法_完整性算法咱们就拿最常见的 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 来拆解：
| 部分 | 值 | 作用 |
|---|---|---|
| 密钥交换 | ECDHE | 双方怎么安全地商量出对称密钥 |
| 认证 | RSA | 用证书里的 RSA 公钥验证服务器身份 |
| 加密 | AES_128_GCM | 用 128 位密钥的 AES-GCM 模式加密数据 |
| 完整性 | SHA256 | 用 SHA-256 做消息认证码（HMAC） |
关键点：TLS 1.3 简化了套件格式，只保留 AEAD 加密和 HKDF 派生，不再暴露认证算法。不过目前大部分环境还是 TLS 1.2 为主，这个拆解法依然是最实用的。
4.2 核心算法选型对比
我在项目中遇到最多的，就是双方支持的套件对不上，导致握手失败。你想想看，哪个环节出问题，都有可能卡死。
咱们重点看两个地方：密钥交换和加密算法。
4.2.1 密钥交换算法
- RSA：传统方案。客户端用公钥加密预主密钥发给服务端。缺点是不支持前向安全性——一旦私钥泄露，之前所有的通信都能被解密。
- DHE（Diffie-Hellman Ephemeral）：每次握手生成临时密钥对，前向安全。但计算量大，握手相对较慢。
- ECDHE：椭圆曲线版的 DHE，使用更短的密钥达到同等安全强度，性能和安全性都更好。我个人习惯优先推荐 ECDHE，兼容性也不错。
- PSK（预共享密钥）：多用于物联网或内部系统，双方提前约定密钥，不需要证书交换。
我的建议：能选 ECDHE 就别选纯 RSA。前向安全太重要了。我曾经帮一个客户排查问题，他们用了 RSA 密钥交换，结果半年后私钥泄露了，几百万条会话记录都得重新保护，教训深刻。
4.2.2 加密算法与模式
常见的对称加密算法有 AES、ChaCha20、3DES。3DES 现在已经被认为不安全，除非兼容老旧设备，否则别用。
| 算法 | 模式 | 位宽 | 认证 | 典型场景 |
|---|---|---|---|---|
| AES | GCM | 128/256 | 带认证（AEAD） | 现代 Web 首选，性能好 |
| AES | CBC | 128/256 | 需额外 HMAC | 老旧系统，有 padding oracle 风险 |
| ChaCha20 | Poly1305 | 256 | 带认证（AEAD） | 移动设备、无 AES 硬件加速的环境 |
| 3DES | CBC | 168 | 需额外 HMAC | 强烈不建议，安全等级过低 |
我的经验：如果客户端是移动设备（尤其 Android 低版本），或者使用 OpenVPN / WireGuard 等场景，ChaCha20-Poly1305 表现非常出色。而在 x86 服务器上，AES-NI 指令集让 AES-GCM 速度更快。选型时要看运行环境。
4.3 如何选择加密套件？
选套件不能盲目追求“最强”，要平衡安全性、兼容性、性能。我一般这样做：
- 淘汰弱套件：禁用 RC4、3DES、CBC 模式（如果必须支持 CBC，确保 TLS 1.2 且只与支持 1.2 的客户端通信）。
- 优选 AEAD：优先选择带认证加密的套件，比如 AES-GCM 或 ChaCha20-Poly1305。
- 保证前向安全：优先使用 ECDHE 或 DHE，禁用纯 RSA 和 DH（静态）。
- 考虑兼容性：如果客户端环境复杂（比如企业内部有 IE11、老旧 Java 客户端），需要保留 CBC 或 SHA-1 套件，但排在最后。
避坑警告：我曾经在调试一个跨公网的 API 服务时，因为服务端只配置了 ECDHE 套件，而客户端的 OpenSSL 版本较老，不支持 P-256 曲线。结果客户端绕过了 ECDHE，走了 DHE 曲线，但服务端又把 DHE 套件排在了后面，握手超时重试了三次才成功。最终定位是套件优先级和曲线支持不匹配。所以选套件时，不仅要看算法，还要看曲线支持情况。
4.4 常用配配置示例
以 Nginx 为例，一个现代安全配置可以这样写：
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;这里我个人习惯把 ChaCha20 的套件放最后，因为大多数服务器对 AES 更友好。如果面向移动端，可以调到前面。
如果你用的是 Apache，配置类似：
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on4.5 加密套件选择的知识结构
下面这张图把整个选择逻辑串起来了。你对照着看，以后遇到握手失败，直接对应查节点。
你看这张图，从收到 ClientHello 开始，先定密钥交换，再选加密算法，最后配上完整性哈希。每一步都影响最终套件的安全级别和性能表现。
嗯，关于加密套件的概念与选择，核心知识点就是这些了。下次你看到那一长串套件字符串，能一眼拆开，也知道该怎么调优了。