1. TLS 1.3 概述与背景
大家好，今天我们开始聊 TLS 1.3。如果你平时写后端服务、处理支付接口、或者调过云厂商的 API，肯定跟 TLS 打过交道。说白了，它就是互联网上保证通信安全的那个“加密隧道”。我自己最早接触的是 SSL 3.0——嗯，暴露年龄了。那时候做电商，被 PCI-DSS 审计搞得焦头烂额，最后发现是协议版本太老被扫出来了。从那以后我就特别关注协议栈的升级。
1.1 协议发展历程
咱们先捋一下时间线。TLS 的前身是 Netscape 公司搞的 SSL，1994年出了 SSL 2.0（漏洞一堆），1995年 SSL 3.0 才算正经可用。后来 IETF 接手，标准化成 TLS 1.0（1999年）、TLS 1.1（2006年）、TLS 1.2（2008年）。2018年 TLS 1.3（RFC 8446）才正式落地。
你可能会问：为什么 TLS 1.2 到 1.3 隔了十年？其实不是没人做，是安全需求变复杂了。我记得 2014 年 Heartbleed 和 POODLE 攻击接连爆出来，业界才开始认真反思协议设计。TLS 1.3 的草案从 2014 年开始改，改了十几个版本才定稿。
发展历程里有个关键节点：大部分老协议已经不建议用了。现在主流浏览器在 2020 年后陆续废弃了 TLS 1.0/1.1。我建议你的服务器至少支持 TLS 1.2 和 1.3，否则部分用户可能连不上。
1.2 设计目标
TLS 1.3 的设计目标很明确：更快、更安全、更简单。我们来拆开看。
- 减少握手延迟：TLS 1.2 完整握手需要 2-RTT（两次往返），TLS 1.3 通过预共享密钥（PSK）和 1-RTT 握手，做到了 1-RTT；如果复用会话甚至能 0-RTT。这可不是简单的性能优化——移动网络和 HTTP/3 场景下，每减少一次往返都能明显改善用户体验。我在某大厂做过压测，把 CDN 节点从 TLS 1.2 切到 1.3，首屏加载时间平均降低 15%。
- 移除不安全特性：TLS 1.3 废弃了 RSA 密钥传输、CBC 模式、静态 DH 等一堆“历史包袱”。说白了，那些在实验室里被攻破的算法统统砍掉。
- 加密握手全过程：握手消息本身也加密了，避免中间人通过 sniff 握手内容推测出密码套件或证书信息。
- 简化密码套件：从上一版几十种减到只剩 5 个 AEAD 套件。选择少了，配置失误的概率就低了。
你想想看，为什么 RFC 要这么激进？因为过去十年里，几乎每个 TLS 1.2 的密码套件都在实际攻击中受过伤。RC4 被破解、CBC 有 padding oracle、RSA 密钥交换没有前向安全性……我曾在安全审计中遇到过一家金融公司还在用 TLS_RSA_WITH_AES_128_CBC_SHA，当场就建议他们停用。
1.3 与 TLS 1.2 的核心区别
光说概念不够，我们直接用表格来看差异，一目了然。
| 对比项 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手轮次（完整握手） | 2-RTT（ClientHello + ServerHello/证书/ServerHelloDone → ClientKeyExchange → ChangeCipherSpec → Finished） | 1-RTT（ClientHello + ServerHello/证书/Finished → Finished） |
| 0-RTT | 不支持 | 支持（需 PSK 和 Anti-Replay 机制） |
| 支持的密钥交换算法 | RSA、DH、ECDH（含静态） | 仅 (EC)DHE（前向安全） |
| 密码套件数量 | 数十种（含 CBC、RC4、Export 等弱套件） | 5 种（均为 AEAD：AES-128-GCM/AES-256-GCM/CHACHA20-POLY1305 等） |
| 握手加密 | 握手后半部分（ChangeCipherSpec 之后）加密 | 整个握手过程（除 ClientHello 部分字段）全部加密 |
| 服务器证书身份 | 必须通过 Certificate 消息明文发送 | Certificate 消息加密发送（隐藏证书链细节） |
| 会话恢复 | Session ID / Session Ticket | PSK + Ticket（结合 0-RTT） |
| 协议协商 | 版本协商在握手之初明文进行 | 通过 supported_versions 扩展，支持降级保护 |
这个表建议你存一下。我在多次面试和方案评审中都拿它当速查卡片。
还有一个很容易踩的坑：降级保护。TLS 1.3 的 ClientHello 里如果包含 supported_versions 扩展，服务器就不能故意降级到 TLS 1.2。但有些老旧中间件不支持这个扩展，客户端又没做 Fallback SCSV，就可能被降级攻击。我曾经在给一个政府项目做安全加固时，发现负载均衡配置了 TLS 1.3，但后端真实服务器只认 1.2，结果中间人插进来把握手降成了脆弱的 TLS 1.1。那之后我养成了一个习惯：所有服务端必须显式禁用旧协议版本，不能靠客户端自己协商。
核心逻辑总览
下面这张图把 TLS 1.3 的演进动机和核心变化串起来了。你可以把它当作本章的思维导图。
你看这张图，左侧是协议演进的时间轴，中间是 TLS 1.3 的设计目标，右侧是落地后的关键区别。箭头表明：正是历史积累的安全问题和性能瓶颈，推动着设计目标变化，最终形成了今天我们在用的 TLS 1.3。
嗯，这里要特别提一句：虽然 TLS 1.3 本身很安全，但实现上依然有容易出问题的地方，比如 0-RTT 的重放攻击、PSK 生命周期管理、降级到 TLS 1.2 的中间人风险。后面章节我们会挨个深入。