TLS 1.2 vs TLS 1.3：差异和升级方法

TLS（传输层安全）是保护浏览器和服务器之间数据的加密协议。TLS 1.2 已成为十多年来的标准，而 TLS 1.3（2018 年定稿）明显更快、更安全。本指南介绍每个版本的历史、比较速度和安全性、展示如何在真实服务器上启用或禁用每个 TLS 版本，并解释如何检查您的网站当前使用的版本。

每个 TLS 版本的历史和状态

TLS 源于 1990 年代的 SSL（安全套接字层）。如今，由于 POODLE 等严重缺陷，每个 SSL 版本（2.0 和 3.0）都已退役，TLS 本身也经历了多个版本。下表总结了 2026 年每个版本的状态 — 是否仍应使用或完全禁用。

简而言之，对于 2026 年，您应该只启用 TLS 1.2 和 TLS 1.3。SSL 3.0、TLS 1.0 和 TLS 1.1 必须完全禁用，因为现代浏览器不再支持它们，PCI DSS 等安全标准禁止使用它们。

关键差异：TLS 1.2 vs TLS 1.3

TLS 1.3 为什么更快、更安全（1-RTT、前向保密）

三件事使 TLS 1.3 优于早期版本：更快的握手、强制前向保密和删除每个弱密码。

使用 1-RTT 的更快握手

在 TLS 1.2 中，建立连接需要浏览器和服务器之间的两个往返（2-RTT）才能进行任何实际数据流。TLS 1.3 将其减少到单个往返（1-RTT），使页面加载明显更快 — 特别是对于远离服务器或在高延迟移动网络上的用户。距离越远，每个节省的往返恢复的时间越多。

返回访客的 0-RTT

当用户之前已连接并返回时，TLS 1.3 支持 0-RTT 恢复，几乎无需新握手即可立即发送数据。这使网站对重复访客感觉快得多。要小心状态改变请求（例如付款）上的重放攻击，因此仅对安全、幂等请求启用 0-RTT。

每个会话强制前向保密

前向保密 (PFS) 意味着即使服务器的私钥在将来泄露，攻击者仍然无法解密之前捕获的流量，因为每个会话都使用自己的临时密钥。在 TLS 1.2 中，这是可选的，取决于密码配置，但 TLS 1.3 在每个会话中自动强制实施。它还将密码套件列表从 37 个减少到仅 5 个已验证的强选项 — 消除了配置错误的风险。

在 Nginx 和 Apache 上启用/禁用 TLS 版本

配置的核心是只启用 TLS 1.2 和 1.3，同时禁用 TLS 1.0/1.1。下面是有效的配置示例。

Nginx — 启用 TLS 1.2 + 1.3，禁用其他

# 在 server { ... } 或 http { ... } 块内
ssl_protocols TLSv1.2 TLSv1.3;   # 省略 TLSv1 / TLSv1.1 将禁用它们
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;   # TLS 1.3 让客户端选择密码

先用 sudo nginx -t 测试语法，然后重新加载 sudo nginx -s reload

Apache — 明确禁用旧 TLS

# 需要 OpenSSL 1.1.1+ 和 Apache 2.4.37+ 来支持 TLS 1.3
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLHonorCipherOrder off

使用 sudo apachectl configtest 验证，然后重新加载 sudo systemctl reload apache2（或 CentOS/RHEL 上的 httpd）

如何检查网站使用哪个 TLS 版本

在调整配置之前和之后，验证服务器支持哪些 TLS 版本。有多种方法，从在线工具到终端命令。

检查您当前的 TLS 版本

方法 1：SSL Labs（最简单）

前往 https://www.ssllabs.com/ssltest/，输入您的域，然后检查 TLS 协议部分。

方法 2：curl

curl -v --tlsv1.3 --tls-max 1.3 https://yourdomain.com 2>&1 | grep "TLS"

方法 3：OpenSSL

openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep "Protocol"

在 Nginx 上启用 TLS 1.3

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

然后重新加载：sudo nginx -s reload

在 Apache 上启用 TLS 1.3

# 需要 OpenSSL 1.1.1+ 和 Apache 2.4.37+
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

应该禁用 TLS 1.0 和 1.1 吗？

是的 — IETF 在 2021 年正式弃用了 TLS 1.0 和 1.1，现代浏览器已停止支持。禁用它们有助于在 SSL Labs 上获得 A+ 并满足 PCI DSS 合规性。

TLS 1.2 和 TLS 1.3 的推荐密码套件

选择正确的密码套件是将安全的 TLS 1.2 配置与过时的配置区分开来的关键。以下是推荐的密码以及您必须从任何服务器配置中删除的密码。

TLS 1.2 的推荐密码

• ECDHE-ECDSA-AES128-GCM-SHA256 — 支持 ECDSA 证书；快速且安全
• ECDHE-RSA-AES128-GCM-SHA256 — 支持广泛使用的 RSA 证书
• ECDHE-ECDSA-AES256-GCM-SHA384 — 敏感数据的更高加密级别
• ECDHE-ECDSA-CHACHA20-POLY1305 — 在没有硬件 AES 加速的设备上比 AES 更快

从 TLS 1.2 配置中删除的密码

• RC4 — 弱，IETF 在 RFC 7465 中禁止
• 3DES / DES-CBC3 — 易受 SWEET32 生日攻击
• NULL 密码 — 完全没有加密；极其危险
• EXPORT 密码 — 为出口而刻意削弱；易受 FREAK 攻击
• RSA 密钥交换（非 ECDHE） — 没有前向保密

5 个 TLS 1.3 密码套件

请注意，TLS 1.3 密码套件的名称中不包含密钥交换算法 — 因为 TLS 1.3 自动为每个会话强制使用 ECDHE。与 TLS 1.2 不同，不再有密钥交换的选择。

在 Windows、macOS 和 DirectAdmin 上检查 TLS 版本

除了 Linux/VPS 服务器上的 curl 和 OpenSSL 之外，还有从其他操作系统和托管控制面板验证 TLS 版本的方法。

通过浏览器 DevTools 检查

对于最终用户来说，最快的方法是 Chrome DevTools。打开目标网站，按 F12，转到安全标签，然后点击"查看证书"。连接部分显示正在使用的 TLS 版本和协商的密码套件。

使用 PowerShell 检查（Windows）

$request = [Net.HttpWebRequest]::Create("https://yourdomain.com")
$request.GetResponse() | Out-Null
[Net.ServicePointManager]::SecurityProtocol

输出显示 Windows 已启用的协议，例如 Tls12, Tls13。

从 DirectAdmin 检查

DirectAdmin 在 Account Manager → SSL Certificates 下显示证书。请注意，面板仅显示证书状态，而不是实际的 TLS 协议配置。使用 SSL Labs 或 curl 进行可靠的 TLS 版本检查。

使用 nmap 进行详细密码审计

nmap --script ssl-enum-ciphers -p 443 yourdomain.com

这列出了每个支持的密码套件及其安全等级（A/B/C），非常适合彻底的安全审计。

TLS 如何影响 SEO 和 Core Web Vitals

升级 TLS 不仅是安全问题 — 它直接影响页面速度和 Google 用于排名的 Core Web Vitals 分数。

TLS 1.3 时 TTFB 下降

TTFB（首字节时间）测量从浏览器发送请求到收到第一个字节的时间。当 TLS 1.3 将握手从 2-RTT 切割到 1-RTT 时，TTFB 会显著下降 — 特别是对于远离您服务器的用户。如果往返延迟为 50 毫秒，消除一个 RTT 节省 50 毫秒的 TTFB，这直接改善您的 LCP（最大内容绘制）分数。

0-RTT 对返回访客的好处

再次访问您网站的用户受益于 TLS 1.3 的 0-RTT 会话恢复，它几乎没有握手开销。结果是对已登录用户和重复访客来说，INP（交互到下一个绘制）和 FCP（首次内容绘制）明显更快。

Google 将 HTTPS 视为排名信号

自 2014 年以来，Google 一直将 HTTPS 视为排名信号。虽然它不直接加权 TLS 版本，但运行 TLS 1.3 的网站在 Lighthouse 中获得更高的最佳实践分数，PageSpeed Insights 不会标记"不安全协议"警告，这可能会损害整体用户体验分数。

HTTP/2 和 HTTP/3 需要 TLS

HTTP/2 在每个浏览器实现中都需要 TLS（尽管规范在技术上允许明文）。HTTP/3（QUIC）直接将 TLS 1.3 嵌入协议中。因此，支持 TLS 1.3 是 HTTP/3 的基线要求，它进一步降低延迟并改善 Core Web Vitals，超过了 TLS 1.2 与 HTTP/2 能达到的水平。

从使用旧版 TLS 的环境迁移

如果您的服务器运行旧版 OpenSSL 或旧版操作系统，启用 TLS 1.3 可能首先需要升级。下表总结了最低要求。

如果您使用的是 AsiaGB 托管等共享或托管主机，系统会自动更新 OpenSSL 和网络服务器。客户无需采取任何措施 — TLS 1.3 从第一天开始就可用且活跃。

关于 TLS 1.2 和 TLS 1.3 的常见问题

我可以只启用 TLS 1.3 吗？

可以，但在 2026 年不建议这样做，因为一些旧设备和浏览器只支持 TLS 1.2。如果您禁用 1.2，那些用户将无法访问您的网站。最好的方法是一起启用 TLS 1.2 和 1.3，以实现最大兼容性，同时保持安全。

升级到 TLS 1.3 需要新的 SSL 证书吗？

否。TLS 是关于连接协议的，而 SSL 证书处理身份验证。您现有的证书立即与 TLS 1.3 兼容 — 您只需更新服务器配置以启用 TLS 1.3，并确保 OpenSSL 是 1.1.1 或更新版本。

禁用 TLS 1.0/1.1 会锁定旧客户吗？

这仅影响非常旧的设备，例如 Windows XP 或 Android 5.0 之前的版本，这些设备现在仅代表一小部分用户。每个现代浏览器都至少支持 TLS 1.2，因此禁用 1.0/1.1 是满足 PCI DSS 合规性的必要且安全的步骤。

我如何知道我的网站是否符合 TLS 安全标准？

最简单的方法是在 SSL Labs (ssllabs.com/ssltest) 上测试您的域。如果您获得 A 或 A+ 分数，并且报告仅显示支持 TLS 1.2/1.3，则您已通过。使用 AsiaGB 托管，TLS 1.3 被启用，旧版本会自动禁用。