TLS/SSL 基础概念：你真的了解它们吗？
讲网关加密之前，我觉得有必要先把地基打牢。你可能会说：“TLS 和 SSL 不就是一回事吗？”
嗯，不能说完全错了。但我在项目里见过不少工程师把两者混为一谈，结果排查证书兼容性问题时踩了坑。今天我们就从零开始捋一捋。
TLS 与 SSL：同根生，但别搞混
SSL 是 Netscape 在 90 年代搞出来的。1.0 版本基本没公开，2.0 和 3.0 才是大家常说的“老 SSL”。后来 IETF 接手，把 SSL 3.0 改吧改吧，改名叫 TLS 1.0。说白了，TLS 1.0 == SSL 3.1。
| 协议 | 发布年份 | 现状 | 我见过的问题 |
|---|---|---|---|
| SSL 2.0 | 1995 | 已废弃（有严重漏洞） | 老设备里还能扫到，必须封禁 |
| SSL 3.0 | 1996 | 已废弃（POODLE 攻击） | 我曾经在内网遗留系统上被迫维护过……痛苦 |
| TLS 1.0 | 1999 | 逐步禁用（BEAST 攻击） | PCI DSS 合规检查时被要求关掉 |
| TLS 1.1 | 2006 | 逐步禁用 | 现在大部分浏览器也不认了 |
| TLS 1.2 | 2008 | 主流（推荐） | 大部分生产环境都在用这个 |
| TLS 1.3 | 2018 | 最新（强烈推荐） | 握手快了一倍，我在性能调优时尝到了甜头 |
千万别手软：SSL 2.0/3.0 和 TLS 1.0/1.1 在服务端配置里直接禁用掉。我曾经接手过一个项目，就因为留着 TLS 1.0 导致被扫出 BEAST 漏洞，紧急打补丁折腾了一宿。
TLS 握手协议流程：一句话说不清，但可以画出来
为什么要搞握手？因为双方要在不安全的信道里，安全地协商出一个对称加密密钥。
你自己想想看：如果直接用非对称加密传输所有数据，性能扛不住。如果直接用对称加密，密钥怎么安全地传给对方？
所以 TLS 握手做了三件事：
- 身份验证——服务器出示证书，证明“我是我”。（可选双向验证）
- 密钥协商——用非对称加密或 DH 系列算法，安全地交换出对称密钥。
- 数据加密——后续通信全部走对称加密，快！
下面这张图是我自己梳理的 TLS 1.2 完整握手流程（省略了 Session Resume 分叉），你把它吃透了，后面讲 Termination 就顺了。
小技巧：TLS 1.3 把这个 2-RTT 握手压缩到了 1-RTT，甚至 0-RTT（需要特殊配置）。如果你在做网关加密，强烈建议优先用 TLS 1.3，一来减少延迟，二来砍掉了不少老旧算法，安全风险也小了。
对称加密 vs 非对称加密：一个快一个安全
这个其实是基础中的基础，但我还是想用你自己的话讲透。
对称加密：加密和解密用同一把钥匙。好比你家大门钥匙，自己锁自己开。快，但是怎么把钥匙给对方？
- 常见算法：AES、ChaCha20、DES（千万别再用）
- 典型场景：TLS 握手完成后，数据段全部用对称加密，扛得住高并发
- 我在项目中遇到过：有一次误配了 AES-256-CBC 而没用 GCM 模式，结果被协议检测工具报出弱加密套件，赶紧切成了 AES-256-GCM
非对称加密：公钥加密，私钥解密。你想想看，公钥全世界都能拿到，私钥只有自己藏着。这就解决了密钥分发问题。但是慢，慢到只能用来加密小数据（比如对称密钥）。
- 常见算法：RSA、ECDH、DHE
- 典型场景：TLS 握手阶段交换预主密钥（Pre-Master Secret）
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 速度 | 快（硬件加速后几十 Gbps） | 慢（通常 < 1Gbps，取决于密钥长度） |
| 密钥管理 | 困难（每对通信方需要独立密钥） | 容易（公钥公开，私钥保密） |
| 典型算法 | AES-256-GCM, ChaCha20-Poly1305 | RSA-2048, ECDHE-P256 |
| 在TLS中的角色 | 加密传输数据（大量） | 身份认证 + 密钥协商（少量） |
核心结论：TLS 就是利用非对称加密的“安全性”来传输对称加密的“钥匙”，之后所有数据都用对称加密跑。这个设计思路也叫“混合加密系统”。理解了这一点，边界网关上的 TLS Termination 原理就懂了一半。
常见误解与避坑
我自己刚开始接触时也迷糊过，这里列几个坑：
- 证书=加密？ 不是。证书只做身份绑定，真正加密靠非对称密钥对里的公钥。
- TLS 1.2 加密套件越多越好？ 大错特错。我曾经见过生产环境配了 30 多个套件，攻击面被撑得巨大。只保留
ECDHE-RSA-AES256-GCM-SHA384这类强套件就够了。 - 自签名证书不能用在生产？ 不一定。内部服务间通信，如果你有内部 PKI 或自己做 CA，自签名是可以的。但对外暴露的服务千万不能用。
曾经踩过的坑：有一次我优化 HTTPS 性能，把对称加密从 AES-256 降级到了 AES-128 想省 CPU，结果被安全团队拦下了。其实 AES-256 在支持 AES-NI 指令集的 CPU 上几乎不额外耗性能，所以别省这点。保持 256 位，心里踏实。