互联网在不断发展。网站规模不断扩大，流量不断变化，攻击者也不断调整。昨天有效的安全措施明天可能就失效了。正因如此，保护网络的技术（例如 Transport Layer Security (TLS) 和新兴的后量子密码学 (PQC)）也必须不断发展。我们希望确保每个人都能自动受益于这种演进，因此我们默认启用了最强大的保护措施。
在 2024 年生日周期间，我们宣布推出 Automatic SSL/TLS：这项服务会扫描 Cloudflare 背后域名的源站配置，并自动将其升级到其支持的最安全的加密模式。在过去的一年里，该系统已悄然为超过 600 万个域名强化了安全防护——确保 Cloudflare 始终能通过最安全的通道连接源服务器，而用户无需进行任何手动操作。
在我们开始启用 Automatic SSL/TLS 一年后的今天，我们想谈谈这些结果、它们为何重要，以及我们如何为互联网安全的下一次飞跃做好准备。
在深入探讨之前，我们先来回顾一下 Transport Layer Security (TLS) 的基础知识。该协议允许两个陌生人（例如客户端和服务器）进行安全通信。
每一次安全的网页会话都始于 TLS 握手协议。在您的数据字节开始在互联网上传输之前，服务器和客户端需要先协商出一个共享密钥，这个密钥将保护您数据的保密性与完整性。而这场密钥协商的握手过程，是从 TLS ClientHello 消息开始的——该消息相当于浏览器/客户端在宣告：“我想要与谁通信（通过 SNI），以及我支持哪些密钥协商方式”。随后，服务器会通过出示证书凭证来证明自身身份，最终双方共同建立一个共享密钥，这个密钥将保护后续所有的通信内容。
TLS 1.3 新增了一个巧妙的快捷方式：浏览器无需等待服务器告知其应使用哪种密钥协议，而是可以猜测服务器支持的密钥协议，并立即添加一个或多个密钥共享。如果猜测正确，握手过程将跳过额外的往返，从而更快地建立安全连接。如果猜测错误，服务器将以 HelloRetryRequest (HRR) 进行响应，告知浏览器应使用哪种密钥协议方法进行重试。这种推测性猜测是 TLS 1.3 比 TLS 1.2 速度快得多的主要原因。
一旦双方同意，所选的密钥共享将用于创建共享秘密，加密双方交换的消息，并仅允许正确的一方解密。
直到最近，大多数此类握手协议仍依赖于使用 X25519 曲线的 Elliptic Curve Cryptography (ECC)。但量子计算机正逐渐成为潜在威胁——它们未来某天可能破解 X25519 等 ECC 算法。为应对这一挑战，业界正转向采用 MLKEM 的后量子密钥协议，并以混合模式 (X25519 + MLKEM) 部署。这种方案能确保即使量子计算机问世，当下截获的网络流量在未来也无法被解密。目前，X25519 + MLKEM 组合正稳步崛起，成为连接 Cloudflare 服务时最受欢迎的密钥协商方案。
TLS 握手模型是我们如今加密网络通信的基础。TLS 的历史实际上是在压力下不断迭代的故事。它是一种必须不断发展的协议，以便网络上的信任能够跟上互联网流量变化的步伐。它也使得 Cloudflare 的 Automatic SSL/TLS 等技术成为可能：它将数十年的协议之争和加密工程简化为一次点击，让客户网站默认受到保护，而无需每个操作员都是加密专家。
20 世纪 90 年代推出的早期 TLS（当时称为 SSL）版本存在密钥强度低、对中间人攻击等攻击的防护有限以及互联网普及率低等问题。为了稳定局势，IETF 介入并发布了 TLS 1.0，随后在 21 世纪又发布了 TLS 1.1 和 1.2。这些版本增加了更强的加密算法并修补了新的攻击手段，但多年的修复和扩展导致协议臃肿不堪，难以发展。
21 世纪 10 年代初标志着一个转折点。在斯诺登泄密事件之后，互联网默认加密的力度加倍。诸如 Let’s Encrypt 等举措、HTTPS 的大规模采用，以及 Cloudflare 自身承诺提供免费 SSL/TLS 等举措，将加密从可选、昂贵且复杂的措施转变为构建更安全互联网的一项简单易行的基本要求。
所有这些势头促成了 TLS 1.3 (2018) 的诞生，它摆脱了遗留包袱，锁定在现代密码套件中，并使加密连接的速度几乎与 TCP 等底层传输协议一样快，甚至在采用 QUIC 协议时还能实现更快的传输速度。
随着内容分发网络 (CDN) 的兴起，它们重塑了 TLS 的部署方式。浏览器不再直接与托管内容的远程服务器（Cloudflare 称之为源站）通信，而是与最近的边缘数据中心通信，而边缘数据中心又可能代表客户端与源服务器通信。
这创建了两个不同的 TLS 层：
实际上，CDN 充当了翻译器的角色：在边缘实现加密现代化的同时，仍能桥接至传统源站。正因如此，即使 CDN 背后的源服务器多年未升级，您也可以通过手机进行极速的 TLS 1.3 会话。
这就是 Automatic SSL/TLS 在我们保护互联网通信中发挥作用的位置。
Automatic SSL/TLS 功能源于 Cloudflare 致力于让网络实现最大程度加密的使命。最初，我们曾耗费大量时间，以 Universal SSL 为“前门”（即从浏览器到 Cloudflare 边缘的连接）构建安全连接，但我们深知，“后门”（即从 Cloudflare 边缘到源服务器的连接）的升级过程会更加缓慢且困难。
我们提供的方案之一是 Cloudflare Tunnel，其中轻量级代理在源服务器附近运行，并通过隧道安全地将流量传输回 Cloudflare。这种方法可确保连接始终使用现代加密技术，而无需对源服务器本身进行任何更改。
但并非所有客户都使用 Tunnel。许多客户将源站直接连接到 Cloudflare 的边缘，而加密方式取决于源服务器的配置。传统上，这意味着客户必须手动选择适用于其源服务器的加密模式，或者依赖 Cloudflare 选择的默认模式。
为了改善选择加密模式的体验，我们在 2021 年推出了 SSL/TLS 推荐工具。
推荐工具会扫描客户的源服务器，然后为其推荐最安全的加密模式。例如，如果推荐工具检测到源服务器使用的是由 Let’s Encrypt 等受信任的证书颁发机构 (CA) 签名的证书，而不是自签名证书，则会建议从 Full 加密模式升级到 Full (Strict) 加密模式。
根据源站的响应方式，推荐工具会告知客户是否可以改进其 SSL/TLS 加密模式，以提高安全性。以下加密模式代表了 SSL/TLS 推荐工具根据源站的响应可以向客户推荐的加密模式：
然而，在推出推荐工具三年后，我们发现了一些令人担忧的问题：在使用推荐工具的两百多万个域名中，只有 30% 的推荐被采纳。相当多的用户不愿完成下一步，即按下按钮通知 Cloudflare 我们可以通过更安全的设置与其源站进行通信。
我们观察到一些不太理想的设置，客户可以升级这些设置而不会影响网站正常运行，但由于各种原因，用户并没有遵循这些建议。因此，我们构建了一个与推荐系统兼容的系统，并默认执行这些建议。
Automatic SSL/TLS 的工作原理是抓取网站，查找 HTTP 和 HTTPS 内容，然后比较结果的兼容性。它还会检查源站提供的 TLS 证书，并检查所提供内容的类型以确保其匹配。如果下载的内容匹配，Automatic SSL/TLS 会将域名的加密级别提升至兼容且更强大的模式，而不会造成网站崩溃的风险。
具体来说，以下是 Automatic SSL/TLS 用于升级域安全性的步骤：
每个域名都会按计划进行扫描，扫描频率为每月一次（或者直至该域名达到所支持的最高加密模式为止）。
扫描会评估域名当前的加密模式。如果当前加密模式低于推荐系统根据探测和内容扫描结果所判定的该域名所能支持的加密级别，系统将开始逐步升级。
Automatic SSL/TLS 开始通过更安全的模式与源站连接来升级域，仅从其流量的 1% 开始。
如果到源站的连接成功，结果将被记录为成功。
如果失败，系统会将故障记录到 Cloudflare 的控制平面并中止升级。流量会立即降级回之前的 SSL/TLS 设置，以确保无缝运行。
如果没有发现问题，则以 10% 的增量对流量应用新的 SSL/TLS 加密模式，直到 100% 的流量使用推荐模式。
一旦 100% 的流量成功升级且没有出现与 TLS 相关的错误，该域名的 SSL/TLS 设置将永久更新。
对 Flexible → Full/Strict 的特殊处理：这些升级更加谨慎，因为客户的缓存键已更改（从 http 到 https 源站方案）。
在这种情况下，流量以 1% 的增量从 1% 增加到 10%，从而使客户的缓存能够预热。
在 10% 之后，系统会恢复到标准的 10% 增量，直到达到 100%。
我们深知透明度和可见性至关重要，尤其是在自动化系统发生变更时。为了让客户及时了解最新动态，每当域名加密模式发生更新时，Automatic SSL/TLS 都会每周向账户超级管理员发送一份摘要。这样，您就能始终了解变更的具体内容和时间。
简而言之，Automatic SSL/TLS 功能将原本需要反复尝试的繁琐过程实现了自动化：它能自动为您的网站找到可支持的最强 SSL/TLS 加密模式，同时确保所有功能正常运行。
到目前为止，我们已允许所有 Free、Pro 和 Business 计划的域名使用 Automatic SSL/TLS。我们也已为所有新域名启用此功能，无论这些域名的套餐类型如何，这些域名都将接入 Cloudflare。很快，我们也将开始为 Enterprise 计划客户启用此功能。如果您已经拥有 Enterprise 域名并希望试用 Automatic SSL/TLS，我们建议您在仪表板的 SSL/TLS 部分或通过 API 启用此功能。
截至本文发布时，我们已为超过 600 万个域名实现了安全升级，且网站运营者无需在 Cloudflare 平台上进行任何手动配置。
先前的加密模式 | 升级的加密模式 | 域名数量 |
Flexible | Full | ~ 2,200,000 |
Flexible | Full (strict) | ~ 2,000,000 |
Full | Full (strict) | ~ 1,800,000 |
Off | Full | ~ 7,000 |
Off | Full (strict) | ~ 5,000 |
最让我们兴奋的是，超过 400 万个域名已从 Flexible 或 Off（使用 HTTP 连接源服务器）迁移到 Full 或 Strict 模式（使用 HTTPS）。
如果您有理由使用特定的加密模式（例如，在尚未准备好投入生产的测试域上），您可以随时禁用 Automatic SSL/TLS 并手动设置最适合您的用例的加密模式。
目前，SSL/TLS 模式在整个域范围内运行，这种方式略显粗放。这意味着一个不太理想的子域可能会导致整个域处于不太安全的 TLS 设置中，从而确保可用性。我们的长期目标是使这些控制更加精确，以便自动 SSL/TLS 和加密模式能够针对每个源或子域优化安全性，而不是对每个主机名一视同仁。
自 2024 年末和 2025 年初开始为域名启用 Automatic SSL/TLS 以来，我们已经能够衡量整个网络的源站连接如何获得更强大的安全性。查看所有源站请求的比率，趋势显而易见：
加密技术正在兴起。明文连接数正在稳步下降，这反映出 Automatic SSL/TLS 正在帮助数百万域名默认迁移到 HTTPS。我们发现明文源站绑定连接数相应减少了 7-8%。尽管如此，一些源站仍然采用过时的配置，应尽快升级以满足现代安全需求。
TLS 1.3 正在蓬勃发展。自 2024 年末以来，TLS 1.3 的采用率急剧上升，目前已占据加密源站流量的大部分（近 60%）。虽然 Automatic SSL/TLS 无法控制源站支持的 TLS 版本，但这种转变对于性能和安全性而言都是一个令人鼓舞的信号。
旧版本协议正逐步淘汰。月复一月，TLS 1.2 的使用率持续下降，而 TLS 1.0 和 1.1 如今已罕见到几乎可以忽略不计。
明文连接数的下降令人鼓舞，但也凸显出大量服务器仍然依赖过时的软件包或配置。例如，可以使用 SSL Labs 等网站来检查服务器的 TLS 配置。然而，仅仅复制粘贴设置来获得高评分可能会存在风险，因此我们鼓励客户仔细检查其源站 TLS 配置。此外，Cloudflare 源站 CA 或 Cloudflare Tunnel 可以提供升级源站安全性的指导。
我们不再着眼于 Cloudflare 面向源站的所有连接网络整体，而是聚焦于通过 Automatic SSL/TLS 功能完成升级的域名所呈现出的具体变化。
截至 2025 年 1 月，大多数域名都已注册 Automatic SSL/TLS，其效果显著：与源站的通信方式几乎发生了 180 度的转变，从纯文本通信转变为加密通信。在此之后，流量模式趋于平稳，反映出整个网络安全连接基线更加稳定。加密流量有所下降，这可能表明一些最初升级的域名手动关闭了 Automatic SSL/TLS。
但故事并未就此结束。在过去两个月（2025 年 7 月和 8 月），我们观察到加密源站流量再次显著上升。这可能反映了客户升级了过时的源站软件包并启用了更强大的 TLS 支持——这证明 Automatic SSL/TLS 不仅提高了加密的门槛，还在持续推动那些尚未充分优化的域名朝着更高的安全水平迈进。
为了进一步探究上述“加密”行，我们想看看 TLS 1.2 和 1.3 之间的差异。最初，我们希望涵盖所有支持的 TLS 版本，但 1.0 和 1.1 版本太小，导致图表出现偏差，因此被剔除。我们发现 Cloudflare 和源服务器之间对 TLS 1.2 和 1.3 的支持率均显著上升。值得一提的是，全网范围内 TLS 1.2 的支持率有所下降，但已自动升级的域名的支持率普遍上升，这可能也预示着源站 TLS 堆栈可能需要进一步更新。
最后，对于 Full (Strict) 模式，我们想要调查已执行的成功证书验证次数。该折线图显示，通过 Automatic SSL/TLS 升级的客户，其证书验证成功率显著提升，幅度约为 40%。
到目前为止，我们已经看到 Automatic SSL/TLS 的推出取得了很大成功，数百万个域名已默认升级到更强的加密模式。我们见证了 Automatic SSL/TLS 帮助提升了面向源站的安全性，尽可能安全地将连接推送到更强的模式，避免了网站崩溃的风险。展望未来，我们会继续将此功能扩展到更多客户用例，助力构建更加密的互联网。
接下来我们将为 Automatic SSL/TLS 构建什么？
我们正在扩展 Automatic SSL/TLS 功能，新增功能可为客户提供更清晰的可见性和更强的控制力，同时确保系统默认安全。首先，我们正在构建一个临时扫描选项，让您可以比每月的标准扫描周期更早地重新扫描源站。这意味着，如果您刚刚轮换了证书、升级了源站的 TLS 配置，或者更改了服务器处理加密的方式，则无需等待下一次预定的扫描——Cloudflare 将能够重新评估并立即将您迁移到更强大的模式。
此外，我们正在开发错误显示功能，该功能将直接在信息中心突出显示源站连接问题，并提供切实可行的补救指导。客户无需事后才发现升级失败或源站更改导致设置不如之前安全，而是能够直接看到问题所在并找到解决方法。
最后，对于新接入的域名，我们计划添加更明确的指导，说明何时完成源站配置，Cloudflare 才能运行首次扫描并设置加密模式。这些改进措施将共同减少意外情况的发生，赋予客户更多自主权，并确保升级过程更加顺畅。我们预计这三项功能将于 2026 年 6 月前全部上线。
展望未来，量子计算机将带来严峻风险：当下加密的数据可能被恶意收集，在未来量子攻击技术成熟时被解密。为应对这种“先收集，后解密”的威胁，业界正转向采用抗量子密码学 (PQC)——这类专门设计用于抵御量子攻击的算法。关于这一主题，我们已在先前的博客文章中进行了详细阐述。
2024 年 8 月，NIST 最终确定了其 PQC 标准：ML-KEM 用于密钥协议，ML-DSA 和 SLH-DSA 用于数字签名。Cloudflare 与行业合作伙伴携手推动了 PQC 的开发和部署。我们部署了混合密钥协议，结合了 ML-KEM（后量子安全）和 X25519（经典密钥），以保护我们服务器和内部系统的 TLS 1.3 流量。截至 2025 年 9 月中旬，约 43% 的人为 Cloudflare 连接已受到混合后量子安全密钥协议的保护，这是互联网迎接量子时代的一个重要里程碑。
但在网络的另一端，情况就不同了。当 Cloudflare 连接到源站时，我们充当客户端，在由托管服务提供商、软件堆栈和中间件组成的碎片化环境中导航。每个源站可能支持不同的加密功能，并且并非所有源站都支持混合后量子握手。
为了管理这种多样性，同时避免连接中断的风险，我们依赖于 HelloRetryRequest。我们不会立即在 ClientHello 中发送后量子密钥共享，而是仅声明支持后量子密钥共享。如果源服务器支持后量子密钥协商，它会使用 HelloRetryRequest 向 Cloudflare 请求后量子密钥共享，并创建后量子连接。缺点是，这额外的往返（来自重试）会抵消 TLS 1.3 的性能提升，在未缓存请求的情况下，这种连接感觉更接近 TLS 1.2。
早在 2023 年，我们就推出了一个 API 端点，让客户能够手动为其源站服务器启用优先使用后量子连接的功能。若开启此设置，我们将跳过额外的往返通信环节，并尝试在 TLS 会话初始阶段就建立后量子加密连接。同样地，我们还把后量子加密保护功能扩展到了 Cloudflare 隧道服务中，使其成为目前实现面向源站的后量子加密保护最便捷的方式之一。
从 2025 年第四季度开始，我们将迈出下一步——实现自动化。正如我们对 SSL/TLS 升级所做的那样，自动 SSL/TLS 将开始测试、提升并启用与源站的后量子握手，无需客户进行任何更改，只要他们的源站支持后量子密钥协商即可。
在后台，我们大约每 24 小时扫描一次活跃源站，以测试对传统密钥协议和后量子密钥协议的支持情况与偏好设置。我们已直接与供应商和客户合作，以识别兼容性问题，并且这套新的扫描系统将完全集成到 Automatic SSL/TLS 中。
其效益远不止于后量子领域。即便对于传统的握手过程，性能优化同样至关重要。当前，默认采用的是 X25519 算法，但我们的扫描数据显示，超过 6% 的源服务器目前更倾向于使用其他密钥协商算法，这会导致不必要的 HelloRetryRequests 和额外的往返通信。通过将扫描数据整合到 Automatic SSL/TLS 功能中，我们不仅能改进传统 TLS 协议的连接建立过程，还能全方位提升连接速度和可靠性。
随着企业和托管服务提供商逐步采用 PQC，我们的初步扫描数据显示：目前已有约 4% 的源服务器可以从后量子首选密钥协议中受益（如下图所示）。自我们于 2023 年开始扫描以来，这一数字增长了 8 倍。随着行业持续向后量子协议迁移，我们预计这一数字将稳步增长。
作为此次变更的一部分，我们还将逐步停止对预标准版本 X25519Kyber768 的支持，转而全面采用最终的 ML-KEM 标准——同样采用混合模式，为从边缘到源站的连接提供支持。
通过 Automatic SSL/TLS，我们很快将默认主动扫描您的源站，将最受欢迎的密钥共享直接发送到您的源站，无需任何额外的往返，从而共同提高源站连接的安全性和性能。
在 Cloudflare，我们始终坚信安全是一项权利，而非特权。从 Universal SSL 到后量子加密，我们的使命始终是让每个人都能免费获得最强大的保护。Automatic SSL/TLS 是我们的下一步——自动将每个域名升级到最佳协议。请检查仪表板的 SSL/TLS 部分，确保其已启用，和数百万网站一样，既筑牢今日防线，亦备战明日挑战。