TLS 1.3 是传输层安全协议的当前版本，于 2018 年 8 月发布为 RFC 8446。它是一次根本性的重新设计——不是增量更新——使 HTTPS 更快、更简单、更安全。
截至 2026 年，62% 的网站支持 TLS 1.3，所有主流浏览器自 2018 年起已支持。
相比 TLS 1.2 的变化
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| 握手 | 2 次往返 | 1 次往返（1-RTT） |
| 恢复连接 | 1 次往返 | 0-RTT（第一条消息即发送数据） |
| 密码套件 | 37 个（许多是弱的） | 5 个（全部安全） |
| 前向保密 | 可选 | 强制 |
| RSA 密钥交换 | 支持 | 移除 |
| 静态 DH | 支持 | 移除 |
| CBC 密码 | 支持 | 移除 |
| RC4、DES、3DES | 部分配置 | 移除 |
| 握手中的 MD5、SHA-1 | 允许 | 移除 |
| 握手中的证书 | 明文（可见） | 加密 |
| 压缩 | 可选 | 移除（防止 CRIME） |
| 重新协商 | 支持 | 移除 |
设计哲学：移除所有可能被错误配置的东西。TLS 1.2 有 37 个密码套件——有些安全，有些已破解。TLS 1.3 只有 5 个，全部安全。
TLS 1.3 的 5 个密码套件
TLS_AES_256_GCM_SHA384 ← Strongest, most common
TLS_AES_128_GCM_SHA256 ← Widely used, slightly faster
TLS_CHACHA20_POLY1305_SHA256 ← Best for ARM/mobile (no AES-NI)
TLS_AES_128_CCM_SHA256 ← IoT/embedded
TLS_AES_128_CCM_8_SHA256 ← IoT/embedded (short tag)你无法错误配置这些——它们都是带有强密钥的 AEAD 密码。没有像 TLS 1.2 那样”意外启用弱密码”的风险。
1-RTT 握手：为什么更快
TLS 1.2 握手（2 次往返）：
Client → Server: ClientHello (supported ciphers)
Server → Client: ServerHello, Certificate, KeyExchange
Client → Server: KeyExchange, ChangeCipherSpec, Finished
Server → Client: ChangeCipherSpec, Finished
[4 messages before encrypted data flows]TLS 1.3 握手（1 次往返）：
Client → Server: ClientHello + KeyShare
Server → Client: ServerHello + KeyShare + Certificate + Finished
Client → Server: Finished
[encrypted data can flow after 1 round trip]客户端在第一条消息中就发送密钥共享参数——无需等待服务器先指定算法。这将握手从 2 次往返缩减为 1 次。
0-RTT 恢复
对于回访者（之前连接过），TLS 1.3 支持 0-RTT——在第一条消息中就发送加密的应用数据：
Client → Server: ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client: ServerHello + response请求在握手完成前就发出。折衷：0-RTT 数据容易受到重放攻击，因此应仅用于幂等请求（GET，而非 POST）。
强制前向保密
在 TLS 1.2 中，可以使用 RSA 密钥交换——服务器的长期 RSA 密钥直接解密预主密钥。如果有人记录流量并稍后窃取服务器的私钥，他们可以解密所有过去的对话。
TLS 1.3 完全移除了 RSA 密钥交换。所有密钥交换使用临时 Diffie-Hellman（ECDHE）——每个连接生成唯一的密钥对。窃取服务器的私钥无助于解密过去的会话。更多关于前向保密 →
加密的证书
在 TLS 1.2 中，服务器的证书（包括域名）在握手时以明文发送。被动观察者可以看到你连接的是哪个站点。
在 TLS 1.3 中，证书在握手密钥派生之后发送——它是加密的。SNI（Server Name Indication）在 TLS 1.3 中仍然可见，但 Encrypted Client Hello（ECH） 未来也会将其加密。
如何启用 TLS 1.3
检查是否已启用
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Expected: TLSv1.3Nginx（1.13+ 配合 OpenSSL 1.1.1+）
ssl_protocols TLSv1.2 TLSv1.3;TLS 1.3 在现代 Nginx 中默认启用——你只需不禁用它。
Apache（2.4.37+ 配合 OpenSSL 1.1.1+）
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1这启用 TLS 1.2 和 1.3。
检查你的 OpenSSL 版本
openssl version
# Needs: OpenSSL 1.1.1+ for TLS 1.3 support如果你的 OpenSSL 较旧，升级它或升级操作系统。
应该只强制 TLS 1.3 吗？
目前不建议。 约 38% 的站点不支持 TLS 1.3，一些客户端（企业代理、Java 8、旧嵌入式系统）只支持 TLS 1.2。今天放弃 TLS 1.2 会锁定一些用户。
推荐配置： 同时支持 TLS 1.2 和 1.3。这为现代客户端提供 TLS 1.3 速度，同时保持兼容性。Google、Cloudflare 和大多数主要站点都是这么做的。
常见问题
TLS 1.3 需要新证书吗？
不需要。同一张证书适用于 TLS 1.2 和 1.3。证书与协议无关——它们包含公钥和 CA 签名，不管哪个 TLS 版本使用它们。
TLS 1.3 影响性能吗？
是的，正面影响。1-RTT 握手在首次连接时节省 50-100ms。0-RTT 恢复完全消除回访者的握手延迟。结合 HTTP/2（需要 HTTPS），TLS 1.3 站点明显更快。
TLS 1.2 还安全吗？
使用 AEAD 密码套件（AES-GCM、ChaCha20-Poly1305）和 ECDHE 密钥交换时是安全的。避免 TLS 1.2 中的 CBC 密码——它们有漏洞（BEAST、Lucky13）。TLS 1.3 更好，但使用现代密码的 TLS 1.2 仍然安全。
有 TLS 1.4 计划吗？
没有 TLS 1.4 的计划。IETF 将 TLS 1.3 视为可预见未来的目标。下一个重大变化将是纳入后量子密钥交换（ML-KEM）作为与现有 ECDHE 的混合方案——这将在 TLS 1.3 内发生，不会作为新版本。