密码学预备知识：四位守护者
真要上手配置 TLS，你会发现绕不开四个老朋友——对称加密、非对称加密、哈希函数、消息认证码。这几个概念，每一项都在 TLS 握手中扮演着关键角色。
我刚开始搞安全时，总觉得这些理论离实战太远。直到有一次排查一个奇怪的握手失败问题，最终定位到是 GCM 模式的实现有 Bug……从那以后我才明白，理解这些基础，就是给自己省时省命。
咱们一个一个来看。
一、对称加密：速度之王
对称加密，说白了就是加密和解密用同一把密钥。速度快得惊人，适合加密大量数据。TLS 里的会话数据，最终都是靠对称加密来保护的。
目前主流的选择就两个：AES 和 ChaCha20。
AES（高级加密标准）
- 密钥长度：128 位、192 位、256 位
- 工作模式：GCM、CCM、CBC…… 但 TLS 1.3 只推荐 GCM
- 硬件加速：现代 CPU 都有 AES-NI 指令，跑起来非常快
为什么 AES 这么普遍？因为它经过十几年的公开洗礼，安全性公认可靠。我自己的经验是，能选 AES-256-GCM 就别犹豫，性能开销几乎可以忽略。
ChaCha20
- 密钥长度：256 位
- 配合：Poly1305 做消息认证
- 优势：软件实现极快，尤其适合没有 AES 硬件加速的移动设备
ChaCha20-Poly1305 是一个绝妙的组合。我记得 Google 在 Android 设备上测试过，它的性能比 AES-GCM 还要好。如果你的终端用户很多是老设备，ChaCha20 可能是更保守的选择。
| 特性 | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| 密钥长度 | 256 位 | 256 位 |
| 硬件加速 | 支持（AES-NI） | 无专用硬件加速 |
| 软件性能 | 一般 | 优秀 |
| 安全审计 | 十余年 | 约 8 年 |
| TLS 1.3 推荐 | 是 | 是 |
二、非对称加密：钥匙交换的基石
非对称加密用一对密钥：公钥加密，私钥解密。速度慢，但解决了密钥分发这个世纪难题。
在 TLS 里，它主要干两件事：身份认证和密钥交换。
RSA（经典但正在老化）
- 密钥长度：2048 位起步，现在推荐 3072/4096 位
- 用途：签名和密钥传输
- 问题：不支持前向安全性
为什么要说前向安全性？假如今天你的私钥泄露了，攻击者可以解开以前所有录制的加密流量。这很要命。
所以我现在几乎不在密钥交换阶段用 RSA。ECDHE 才是正道。
ECDHE（椭圆曲线 Diffie-Hellman 临时密钥）
- 曲线：X25519、P-256、P-384、P-521
- 核心优势：每次握手生成临时密钥对，即使长期私钥泄露，也解不开历史的流量
- 性能：比 RSA 快几个数量级
ECDHE + 签名算法是现代 TLS 的标准配置。我个人习惯用 ECDHE-ECDSA 的组合，比起 ECDHE-RSA，证书链少一次验证开销，双方都省事。
三、哈希函数：数据的指纹
哈希函数能把任意长度的数据，压缩成固定长度的摘要。不可逆，且任何微小改动都会让结果面目全非。
TLS 用它来保证数据的完整性——如果有人篡改了数据，哈希值一比较立刻现形。
SHA-2（当前主流）
- 变体：SHA-224、SHA-256、SHA-384、SHA-512
- 安全强度：SHA-256 及以上被认为是安全的
- 性能：64 位平台上 SHA-512 比 SHA-256 还要快，因为它在 64 位字长上运算
嗯，这里有个小技巧。如果你部署的服务器是 x64 架构，用 SHA-512 签名证书或做 HMAC 反而比 SHA-256 快，资源消耗却差不多。
SHA-3（新兴选手）
- 设计：基于 Keccak 海绵结构，与 SHA-2 完全不同
- 安全性：理论上抗碰撞能力更强
- 实际应用：TLS 1.3 未强制要求，目前支持度有限
我在项目中还不怎么用 SHA-3 签证书，因为 CA 那边支持率太低。但在内部校验、固件签名里用 SHA-3 感受过，真的很稳。
| 算法 | 输出长度 | 安全性 | TLS 使用 |
|---|---|---|---|
| SHA-256 | 256 位 | 高 | 广泛 |
| SHA-384 | 384 位 | 高 | 广泛 |
| SHA-512 | 512 位 | 极高 | 较少 |
| SHA3-256 | 256 位 | 高 | 实验中 |
四、消息认证码（MAC）：双重保险
想象一下，数据在传输过程中被中间人截获，改了内容再发给你。你收到后，用哈希函数验证，发现摘要不一样，就知道出问题了。
消息认证码（MAC）干了同样的事，但多了一个密钥。只有持有密钥的双方，才能计算出正确的 MAC 值。
这样一来，攻击者即使能篡改数据，也造不出有效的 MAC——因为没有密钥。
HMAC（最常用的 MAC）
- 构造：
HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m)) - 依赖：底层哈希函数（通常用 SHA-256 或 SHA-384）
- 场景：TLS 1.2 中的记录层完整性
你可能会问：为什么要套这么复杂？直接用哈希函数加个密钥不就行了吗？
嗯，不行。简单的拼接方式有很多已知攻击，比如长度扩展攻击。HMAC 的设计专门防止这类问题，是经过验证的保险方案。
知识结构总览
这几个概念串起来，就构成了 TLS 安全基石的完整拼图。下面这张图帮你理清脉络：
你想想看，这四个东西串起来，才构成一条完整的 TLS 安全链路。任何一个薄弱，整个连接都是纸糊的。
实战小结
- 对称加密：AES-256-GCM 是首选，ChaCha20-Poly1305 适合没有硬件加速的场景
- 非对称加密：ECDHE 做密钥交换，ECDSA 或 RSA 做签名——别用 RSA 加密密钥
- 哈希：SHA-256 就够用，SHA-384 在特定场景下比 SHA-256 更优雅
- MAC：TLS 1.3 用 AEAD 搞定，但你看到 HMAC 别慌——它只是被封装了