1. TLS协议概述与加密原理归纳总结
TLS，全称 Transport Layer Security，中文叫传输层安全协议。说白了，它就是在网络上给数据穿一件加密外套。你访问 HTTPS 网站、收发加密邮件、调用 API 接口——背后都是 TLS 在撑腰。
我刚开始搞安全运维那会儿，总觉得 TLS 就是配个证书就完事。结果有一次线上服务突然报「证书验证失败」，排查了大半天才发现是加密套件顺序配反了，客户端和服务端谈不拢，直接降级到了不加密的 null 套件……嗯，那次之后我再也不敢轻视 TLS 配置了。
1.1 TLS 在协议栈里的位置
TLS 工作在传输层（TCP）之上，应用层之下。它不关心你上层跑的是 HTTP、FTP 还是 SMTP，只负责把数据加密后扔给 TCP，再从 TCP 收回来解密。你想想看，如果把网络比作寄快递，TLS 就是那个给包裹加密码锁的打包员。
下图展示了 TLS 在整个网络协议栈中的位置：
核心要点：TLS 本身不加密「整个网络」，它只加密从应用层交给传输层的那一段数据。中间的任何一跳（比如路由器、负载均衡）如果没配 TLS，数据就是裸奔的。
1.2 TLS 的核心加密原理
TLS 用了三种密码学武器：
- 非对称加密——用来安全交换对称密钥。我习惯称它为「信封」，公钥锁住，私钥打开。
- 对称加密——实际传输数据时用的加密方式。速度快，密钥只有一个。
- 哈希与消息认证码——保证数据没被人中途篡改。你下载文件时看到的 SHA-256 就是这类。
为什么非得这么复杂？我举个例子：如果你直接拿对称密钥传，那怎么把密钥安全交给对方呢？用非对称加密先传密钥，后面再用对称加密传数据——这就是 TLS 的经典做法。
1.3 TLS 握手流程速览
TLS 握手说白了就是一段「你好 – 收到 – 搞定」的协商过程。下面我用最简化的 TLS 1.2 握手来演示：
- 客户端发 ClientHello（支持的 TLS 版本、加密套件列表、随机数）。
- 服务端回 ServerHello（选定版本、加密套件、随机数） + 证书 + ServerHelloDone。
- 客户端验证证书，生成 PreMaster Secret，用服务端公钥加密后发过去。
- 双方各自算出 Master Secret，然后发 ChangeCipherSpec 通知后面要用对称加密了。
- 最后握手完成，开始传输真正的 Application Data。
我曾经在生产环境遇到一个坑：服务端证书的 Subject Alternative Name (SAN) 里漏了域名，结果 Chrome 直接报 NET::ERR_CERT_COMMON_NAME_INVALID。客户端验证证书这步没通过，握手直接挂掉——所以证书配置不能只看有效期，SAN 字段更重要。
避坑指南：我在线上排查过很多次「TLS握手失败」，十有八九是证书链不完整。服务端只发了叶证书，没发中间 CA 证书。客户端收到后找不到根，直接拒绝连接。解决办法很简单：把完整的证书链（从叶证书到根证书的中间件）拼在一起下发。
1.4 加密套件（Cipher Suite）的概念
加密套件就是一组算法的组合。TLS 客户端和服务端必须在握手里商量好到底用哪一套。常见的加密套件名称像这样：
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384拆开来看：
| 字段 | 含义 | 备注 |
|---|---|---|
| TLS | 协议前缀 | 固定 |
| ECDHE | 密钥交换算法 | 临时椭圆曲线 Diffie-Hellman，支持前向安全 |
| RSA | 身份认证算法 | 用 RSA 签名验证证书 |
| AES_256_GCM | 对称加密算法 + 模式 | 256位密钥 + Galois/Counter Mode（带认证） |
| SHA384 | 伪随机函数 / 消息认证码 | 使用 SHA-384 做 HMAC |
我个人建议，现代服务只开启 ECDHE + AES-GCM 系列的套件。像那些带 CBC 模式的套件（比如 AES_128_CBC）容易有填充预言攻击，能关就关。我曾经帮客户审计一个金融平台的配置，发现他们居然还开着 TLS_RSA_WITH_3DES_EDE_CBC_SHA……那可是 2018 年之后就该废弃的算法。
注意：很多配置错误案例的根本原因就是加密套件列表过长、顺序不当，导致客户端强制协商到弱套件。记住一条原则：只保留前向安全（DHE/ECDHE）且支持 AEAD（GCM/CCM）的套件，其他一律删除。
1.5 TLS 1.2 vs TLS 1.3：简化的力量
TLS 1.3 比 1.2 少了整整一次往返（1-RTT 握手），而且砍掉了一堆不安全的算法。我一直推荐新项目直接用 TLS 1.3，如果必须兼容老客户端，至少关闭 SSL 3.0 和 TLS 1.0/1.1。
| 对比项 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手往返 | 2-RTT（完整握手） | 1-RTT（完整握手） |
| 零往返模式 | 不支持 | 0-RTT（需要谨慎使用） |
| 支持的密钥交换 | RSA、DH、ECDH、DHE、ECDHE | 仅 DHE/ECDHE（强制前向安全） |
| 支持的对称加密 | 多种（含 CBC、GCM、CCM） | 仅 AEAD（AES-GCM、ChaCha20-Poly1305） |
| 兼容性 | 最广 | 较好，但部分老客户端不支持 |
嗯，这里要特别强调：即使切换到 TLS 1.3，证书配置该踩的坑一个都不会少。我见过有人升级 1.3 后忘了更新证书链，结果握手依然报错——协议版本再新也救不了证书问题。
1.6 本章小结：你应该记住的三件事
- TLS 加密不是「全自动」的——配置顺序、证书链、加密套件列表，每一项都可能是炸弹。
- 理解握手流程才能定位问题——看到「handshake failure」不要慌，先确认客户端收到的服务器证书是否完整可信任。
- 保持简单、保持现代——只启用 ECDHE + AEAD 套件，只支持 TLS 1.2+，拒绝一切过时算法。
接下来每一章，我都会带你亲手拆解一个真实的 TLS 配置错误案例。咱们从握手开始，一步一步把那些隐蔽的坑挖出来填平。