TLS 加密原理：对称、非对称、哈希算法归纳总结

今天我们来聊聊 TLS 底层的三大加密算法。说白了，TLS 的安全就靠这三兄弟撑起来的。我做 DLP 检测这些年，碰到过不少因为搞混它们而放跑数据的案例。先把它们掰开揉碎讲清楚，后面实战才不慌。

2.1 对称加密：一把钥匙开一把锁

对称加密，就是你和我用同一个密钥，你加密，我解密。速度快得飞起，加解密几千字节也就几微秒。TLS 里数据真正传输时，用的就是对称加密。

我在项目中遇到过一件事：某客户内部邮件系统，TLS 流量突然暴增，但 DLP 设备完全看不懂。后来发现他们用的密码套件是 RC4（你猜对了，出名的弱算法）。我让团队换成了 AES-GCM，问题立刻解决。

2.2 非对称加密：公钥私钥，分工明确

非对称加密，一对密钥：公钥公开，私钥自己留着。你想给我发加密消息？拿我公钥加密，只有我私钥能解开。反过来，我用私钥签名，你拿我公钥验签，证明消息确实是我写的。TLS 握手阶段，非对称加密用来交换对称密钥，或者做数字证书验签。

我曾经帮客户排查过一起 TLS 握手失败：对方证书链里的 CA 公钥长度才 1024 位，现代浏览器根本不信任。你想想看，1024 位的 RSA 在 2025 年就跟纸糊的一样。现在业界底线是 2048 位，推荐 3072 或 ECDSA。

常见算法：RSA（最经典）、ECDSA（椭圆曲线，短小精悍）、Ed25519（新兴高性能）。TLS 1.3 默认倾向使用 ECDHE（椭圆曲线 Diffie-Hellman Ephemeral），每次握手生成临时密钥对，完美前向保密。

2.3 哈希算法：数据指纹，不可逆

哈希不是加密，是「摘要」。你输入任意长度数据，输出固定长度哈希值。SHA-256 输出 256 位，SHA-384 输出 384 位。哈希用来：

• 完整性校验——确保数据没被人篡改
• 数字签名中的摘要
• TLS 握手中的 Finished 消息校验

2.4 三者在 TLS 握手中的协同

你想想看，为什么 TLS 不只用一种？

1. 非对称加密做身份认证和密钥协商（握手开始）
2. 哈希保证握手过程双方没有篡改（Certificate Verify、Finished）
3. 对称加密：一旦协商出对称密钥，后面大量业务数据全用对称加密，快且安全

2.5 实战要点一览

最后给你列几个我踩过的坑，直接记下来当提醒：

• 不要用弱密码套件——服务端配置里务必禁用 TLS 1.0/1.1、RC4、3DES、CBC 模式的 AES 等。我建议用 TLS 1.2 以上，强制 ECDHE + AES-GCM。
• 哈希碰撞不是玩笑——虽然 SHA-256 还没被真实验证碰撞，但 SHA-1 已经有公开碰撞攻击。别赌。
• 证书密钥长度——RSA 至少 2048，ECDSA 至少 P-256。你翻翻扫到的 TLS 证书，很多还是 1024 位的古董。
• DLP 检测的入口——没有解密密钥就无法检测内容层。常用做法是 SSL 中间人代理、或者只做 SNI/证书检测。我个人偏好在网络边界部署 SSL 解密网关，然后在解密后的流量上做内容检测。