什么是 TLS 1.3：HTTPS 握手优化与安全增强

TLS 1.3（传输层安全协议第 1.3 版）是指用于在客户端与服务器之间建立加密连接的最新一代安全协议，由 IETF 于 2018 年 8 月发布（RFC 8446）。它解决的核心问题是如何在不牺牲安全性的前提下，让 HTTPS 握手更快、更难被破解。对部署网站或服务器而言，理解 TLS 1.3 如何优化握手流程、删除了哪些旧算法，有助于评估主机环境的安全配置是否符合当前标准。

定义与背景

TLS（Transport Layer Security，传输层安全协议）的前身是 SSL（Secure Sockets Layer，安全套接层），目前浏览器地址栏中的”HTTPS”即指在 HTTP 之下运行 TLS。TLS 1.3 之前的主流版本是 2008 年发布的 TLS 1.2。随着计算能力提升与密码学研究进展，1.2 及更早版本中的一部分算法与握手机制被认为存在被攻破的风险，因此 IETF 在制定 1.3 版本时采取了”做减法”的策略：不是继续叠加新功能，而是直接移除已知不安全的组件。

从发布时间线看，TLS 1.3 经历了约四年的标准化过程，其间草案版本多达 28 个，是 TLS 历史上讨论最充分的一次修订。主要浏览器与服务器软件（如 Chrome、Firefox、OpenSSL、Nginx）在 2018 至 2020 年间陆续完成默认支持。对网站运营者而言，这一时间线意味着：当前主流用户环境已普遍具备 TLS 1.3 能力，是否启用更多取决于服务器端配置而非客户端兼容性。

工作原理：握手流程如何被精简

传统 TLS 1.2 握手需要客户端与服务器之间往返两次（2-RTT），才能开始发送加密的应用数据。TLS 1.3 将这一过程压缩为一次往返（1-RTT）：客户端在第一条消息中就”猜定”密钥交换参数并携带加密的应用数据，服务器在单次回应中即可完成密钥确认。从技术架构上看，这一优化的代价是客户端必须预先支持有限的密钥交换选项，而协议本身不再允许双方在握手中临时协商算法。

TLS 1.3 还引入了 0-RTT（零往返）模式：对曾经访问过的站点，客户端可以在正式握手完成前就携带加密数据发出请求。该模式可进一步降低重复访问的延迟，但存在”重放攻击”边界——攻击者若截获 0-RTT 数据，可以向服务器重复提交同一请求。因此 RFC 8446 建议 0-RTT 数据只用于幂等操作（如 GET 请求），涉及资金扣减、状态变更的接口应拒绝处理 0-RTT 数据。理解这一边界有助于判断业务是否适合开启该特性。

握手精简对实际延迟的影响可量化：每次 TLS 往返在高带宽消耗的跨洋链路上通常意味着数十至数百毫秒。将握手从 2-RTT 降至 1-RTT，理论上节省一次完整往返；配合 HTTP/2 或 HTTP/3 时，页面首字节时间（TTFB）的改善更为明显。这也是 CDN 与现代主机面板默认开启 TLS 1.3 的主要原因之一。关于 CDN 如何加速访问，可参考CDN（内容分发网络）的定义与作用。

安全增强：移除了哪些旧算法

TLS 1.3 最显著的变化是删除了一整类不再安全的加密组件，主要包括：

• 静态 RSA 密钥交换：不再允许仅用 RSA 加密协商密钥，强制要求具备前向保密（Forward Secrecy，即服务器私钥日后泄露也无法解密历史流量）的算法，如 ECDHE。
• RC4、3DES 等流密码与老分组密码：这些算法已被证明存在实际攻击路径，1.3 的加密套件列表中完全移除。
• CBC 分组模式：改为仅支持 AEAD（认证加密）套件，如 AES-GCM 与 ChaCha20-Poly1305，避免填充预言类攻击。
• MD5 与 SHA-1 签名：握手签名改用 SHA-256 及以上摘要算法。
• 压缩与重协商：两者历史上都引入过严重漏洞（如 CRIME 攻击与重协商漏洞），1.3 直接取消。

做减法的结果是 TLS 1.3 的加密套件数量从 1.2 的三十多个缩减到 5 个左右。套件越少，配置出错的概率越低，安全审计也更容易。对服务器管理员而言，启用 TLS 1.3 通常只需在 Nginx 或 Apache 中添加一行配置并重载服务；但若仍在使用只支持旧算法的客户端，则需要评估是否保留 TLS 1.2 作为兼容回退。关于证书部署本身，可参考一文看懂 SSL 证书的作用与种类。

TLS 1.3 与 TLS 1.2 对比

对比可见，1.3 并非 1.2 的增量升级，而是一次结构性重设计。两版协议在现实中会长期共存：服务器一般同时监听两版，由客户端在握手中选择。对于面向全球用户的网站，保留 1.2 回退可以覆盖极少数旧设备；对于内部系统或 API 服务，若调用方完全可控，则可以直接只启用 1.3 以缩小攻击面。

应用场景与部署建议

TLS 1.3 适合三类典型场景。第一类是面向公众的 HTTPS 网站：主流浏览器均已支持，开启后可改善首访延迟，加密的握手内容还能降低域名与证书信息被中间设备窥探的范围。第二类是 API 与移动应用后端：移动网络的高延迟环境对往返次数敏感，1-RTT 与 0-RTT 的收益在这里最明显，但如前所述，需评估 0-RTT 的重放边界是否与业务逻辑冲突。第三类是服务间的内部加密通信：在调用方版本可控的前提下，只启用 1.3 可显著简化密码配置审计。

部署时应核对三点：服务器软件版本是否支持（OpenSSL 1.1.1 及以上、Nginx 1.13 及以上、较新的面板环境一般默认具备）；加密套件配置是否同时保留 1.2 所需的兼容项；证书链是否完整。若站点同时使用了 CDN 或高防代理，还需确认中间层是否透传 1.3 握手，否则实际生效的可能是边缘节点与源站之间的旧版本。建议在启用后用 SSL Labs 之类的公开检测工具复测握手结果与评级，以配置实证为准而非以面板开关为准。

对于需要评估服务器网络环境与安全配置的读者，可以结合美国服务器的数据安全防护要点一并核对整体方案，把协议版本、证书管理与链路防护作为同一张检查表处理。

常见误区

启用 TLS 1.3 就等于网站安全？不成立。TLS 解决的是传输过程中的窃听与篡改，不覆盖服务器漏洞、弱口令、应用层注入等问题。协议版本只是整体安全基线的一项。

0-RTT 可以无条件开启以追求最快速度？不可以。0-RTT 数据可被重放，涉及写操作的接口必须显式拒绝，否则可能被利用重复提交订单或请求。

TLS 1.3 与 SSL 证书是两回事？常见混淆点。证书是身份凭证，TLS 是传输协议；1.3 并不改变证书的申请与验证方式，只改变握手时如何使用证书。

参考资料

本文技术描述以 RFC 8446（IETF，2018）与主流实现文档为依据；版本时间线与算法移除清单可对照 RFC 原文核实。延伸阅读：

• 域名解析 DNS 全过程详解
• 反向代理与负载均衡的入口层原理