TLS卸载与负载均衡架构设计实战 - 第1节
1.1 为什么我们要聊TLS？
做网络架构的，没人能绕过TLS。我刚开始接触负载均衡那会儿，总觉得TLS是安全工程师的事，跟我们架构没啥关系。后来被坑了一次——生产环境证书过期，整站挂了半小时。嗯，从那以后我老老实实把TLS卸载画进了拓扑图里。
说白了，TLS就是给HTTP套了层加密外壳。你访问一个https网站，客户端和服务器之间走的所有数据都是密文。中间人抓包抓到的全是乱码。
1.2 TLS协议简史：别用老掉牙的版本
TLS前身是网景公司在90年代搞的SSL。版本迭代到现在，淘汰了好几个。
| 协议 | 发布年份 | 状态 | 我见过的坑 |
|---|---|---|---|
| SSL 2.0 | 1995 | ❌ 禁止使用 | 2011年PCI合规扫出来过，吓一跳 |
| SSL 3.0 | 1996 | ❌ 禁止使用 | POODLE漏洞，我当年连夜打补丁 |
| TLS 1.0 | 1999 | ⚠️ 强烈建议禁用 | BEAST攻击，很多老系统还在用 |
| TLS 1.1 | 2006 | ⚠️ 建议禁用 | 2018年后浏览器开始报不安全 |
| TLS 1.2 | 2008 | ✅ 当前主力 | 大多数生产环境用这个，稳定 |
| TLS 1.3 | 2018 | ✅ 推荐 | 握手快了一个RTT，我在CDN上跑了两年了 |
⚠️ 避坑： 我曾经在政府项目里发现还有SSL 3.0的配置，对方说“一直这样没出过问题”。你想想看，不出问题不代表没问题。2024年了，最低也得TLS 1.2。
1.3 加密原理：两把钥匙的故事
TLS核心就两个东西：对称加密和非对称加密。对称加密快，但密钥分发麻烦。非对称加密慢，但能解决密钥交换问题。
我习惯这么理解：
- 对称加密：一把钥匙开一把锁。双方都有相同密钥，加密解密都用一个密钥。典型的AES、ChaCha20。
- 非对称加密：两把钥匙，公钥加密、私钥解密。RSA、ECDSA。
- TLS实际做法：用非对称加密安全地交换一个临时对称密钥，然后后续所有数据都用对称加密。既安全又高效。
为什么不用纯非对称？我做过压测，RSA 2048每秒只能做几百次握手。换成AES-128-GCM，每秒几百万次。不是一个量级。
1.3.1 关键术语速查
| 术语 | 说明 | 我的备注 |
|---|---|---|
| 对称密钥 | 加密和解密用同一个密钥 | 长度通常128/256位 |
| 公钥/私钥 | 公钥加密，私钥解密 | 私钥泄漏等于裸奔 |
| 会话密钥 | 每次连接临时生成的对称密钥 | 用完就丢，不持久化 |
| 数字签名 | 私钥签名，公钥验证 | 用于证书防篡改 |
1.4 握手过程：四步走，一步不能少
我把TLS 1.2完整握手拆成4个大步。你想象一下客户端和服务器的对话。
- ClientHello：客户端说“嗨，我支持TLS 1.2，密码套件列表给你，随机数给你”。
- ServerHello + 证书：服务器回“好，就用TLS 1.2 + ECDHE-RSA-AES128-GCM-SHA256，这是我的证书链，还有我的随机数”。
- 密钥交换 + 证书校验：客户端验证证书链合法性，然后用服务器的公钥加密一个临时秘密发过去。两边各自算出相同的对称密钥。
- ChangeCipherSpec + Finished：两边宣布“后面都用对称密钥加密了”，然后发一条加密的Finished消息确认握手成功。
💡 我调优的一点经验： TLS 1.3把握手从2-RTT降到1-RTT。如果你做负载均衡卸载，务必开启TLS 1.3，尤其高并发场景，延迟能降20-30ms。
下面这张图概括了整个逻辑：
1.5 证书链：谁给你的信任？
证书是TLS信任的基石。你访问baidu.com，浏览器凭什么相信这个服务器真的是百度？因为证书链。
证书链长这样：
- 根证书：操作系统或浏览器内置的CA根。自己签名自己，叫自签名。全球就那么几家：DigiCert、GlobalSign、Let's Encrypt（受信任后也算）。
- 中间证书：根CA签发下级CA，用于安全隔离。根证书离线存着，中间证书在线签发。
- 服务器证书：真正的网站证书，包含域名、公钥、有效期、签名。
校验过程：浏览器拿到服务器证书→用中间证书公钥验证服务器证书签名→用根证书公钥验证中间证书签名→根证书在信任列表里。全过，信任成立。
我在项目中踩过的坑： 有一次给客户部署负载均衡，明明证书配置对了，浏览器还是报“不安全”。查了半天，发现少配了中间证书。服务器只发了服务器证书，链条断了。那以后我每次配证书都拿openssl s_client -showcerts跑一遍，确保完整链。
1.5.1 常见证书类型对比
| 类型 | 验证级别 | 常用场景 | 成本 |
|---|---|---|---|
| DV（域名验证） | 仅验证域名所有权 | 普通网站、API | 免费（Let's Encrypt） |
| OV（组织验证） | 验证域名 + 企业身份 | 企业官网、电商 | 几百～几千元/年 |
| EV（扩展验证） | 严格验证企业法律身份 | 银行、证券、政府 | 几千～上万元/年 |
我个人习惯：内部服务用自签名或私有CA，省钱省事。对外服务用DV，配自动续期。只有合规严控场景才考虑OV/EV。
1.6 本章小结（不预告下一章）
这一节我们搞清楚了三件事：
- TLS版本迭代历史，别再用老古董。
- 对称+非对称混合加密的原理，为什么非对称只用来握手。
- 握手四步走和证书链信任模型。
这些都是后面理解TLS卸载的必修课。你想想看，如果你不清楚握手过程，怎么判断卸载点应该放在哪一步？嗯，后面我们会一步步拆开。