Cloudflare Radar 已经提供了各种安全见解，从应用层和网络层攻击到恶意电子邮件消息，再到数字证书和互联网路由。
今天我们将推出更多功能。我们将发布 Radar 中几个新增的安全相关数据集和工具：
我们将后量子加密 (PQ) 监测范围从客户端扩展到面向源服务器的连接。我们还发布了一款新工具，可帮助您检查网站的后量子加密兼容性。
Radar 中新增的“密钥透明度”部分将提供一个公共仪表板，显示端到端加密消息服务（例如 WhatsApp）的密钥透明度日志的实时验证状态，以及 Cloudflare 审计人员最后一次签名和验证每个日志的时间。该页面作为一个透明的界面，可供任何用户监测公钥分发的完整性，并访问 API 来独立验证 Cloudflare 审计人员的资质证明。
路由安全见解功能持续扩展，新增了关于 ASPA 部署的全球、国家/地区以及网络级别信息。ASPA 是一种新兴标准，可帮助检测和防范 BGP 路由泄漏。
自 2024 年 4 月以来，我们一直在 Cloudflare Radar 上跟踪客户端对后量子加密支持的总体增长情况，记录其全球增长增长情况：从 2024 年初的不足 3% 增长到 2026 年 2 月的超过 60%。2025 年 10 月，我们新增了一项功能，允许用户检查其浏览器是否支持 X25519MLKEM768，这是一种结合了经典 X25519 与 ML-KEM（由 NIST 标准化的、基于格的后量子算法）的混合密钥交换算法。这可以同时抵御经典攻击和量子攻击。
然而，用户到 Cloudflare 连接的后量子加密支持只是问题的一部分，还不是全貌。
对于非 Cloudflare CDN 缓存的内容或无法缓存的内容，Cloudflare 的边缘服务器会与客户的源服务器建立单独的连接来检索这些内容。为了加速向面向源服务器的此类请求过渡到抗量子加密的安全机制，我们之前推出了一个 API，支持客户选择优先使用后量子加密连接。如今，我们在 Radar 中显示源服务器的后量子加密兼容性。
Radar 中新增的源后量子加密支持图显示了支持 X25519MLKEM768 的客户源的比例。这些数据源自 Cloudflare 自动化 TLS 扫描程序，该扫描程序探测与 TLS 1.3 兼容的源服务器，并每天汇总结果。值得注意的是，我们的扫描程序旨在测试源服务器的支持情况，而不是测试其特定偏好。虽然源服务器可能支持后量子密钥交换算法，但其本地 TLS 密钥交换偏好最终将决定加密结果。
虽然主图重点关注后量子安全就绪度，但扫描程序还会评估是否支持经典密钥交换算法。在 Radar Data Explorer 视图中，您还可以查看这些受支持的 TLS 密钥交换算法的完整分布情况。
如上图所示，目前大约 10% 的源服务器可能受益于后量子优先的密钥协议。与 2025 年初的不到 1% 相比，这是一个显著的飞跃，一年多时间里增加了 10 倍。我们预计，随着行业继续迁移，这个数字将稳步增长。这种增长趋势在 2025 年可能会加速，因为许多服务器端 TLS 库（例如 OpenSSL 3.5.0+、GnuTLS 3.8.9+ 和 Go 1.24+）默认启用混合后量子密钥交换，这让平台和服务提供商只需升级其加密库依赖项即可支持后量子连接。
除了 Radar 和 Data Explorer 图表之外，也可以通过 Radar API 获取源服务器就绪数据。
为了进一步帮助互联网过渡到后量子加密，我们还推出了一款工具，用于测试特定主机名是否支持后量子加密。可以在任何可公开访问的网站上运行这些测试，只要网站允许来自 Cloudflare 出口 IP 地址范围的连接。
Radar 中用于测试主机名是否支持后量子加密的工具的屏幕截图。
这款工具提供一个简单的表单，供用户在其中输入主机名（例如 cloudflare.com 或 www.wikipedia.org），然后选择性指定自定义端口（默认是 443，即标准的 HTTPS 端口）。单击“Test”后，结果会显示一个标签，指明后量子加密支持状态以及协商的 TLS 密钥交换算法。如果服务器优先使用后量子加密安全连接，则会出现一个绿色的“PQ”标记，并显示一则消息，确认这是“后量子加密安全”连接。否则，红色标记表示连接“非后量子加密安全”连接，并显示协商的经典算法。
在表面之下，这款工具其实使用了Cloudflare Containers，这是支持与 Workers 一起运行容器工作负载的一项新功能。因为 Workers 运行时无法访问底层 TLS 握手的详细信息，所以 Workers 无法启动 TLS 扫描。因此，我们创建了一个 Go 容器，利用 crypto/tls 包对后量子加密兼容性检查的支持。该容器按需运行并执行实际握手以确定协商的 TLS 密钥交换算法，并通过 Radar API 返回结果。
通过增加这些面向源服务器的见解，与现有面向客户端的见解相得益彰，我们已将所有后量子内容移至 Radar 中的专属部分。
WhatsApp 和 Signal 等端到端加密 (E2EE) 消息应用程序已成为私密通信的重要工具，拥有数十亿全球用户。这些应用程序使用公钥加密技术确保只有发送方与接收方才能读取消息，甚至即使是消息服务本身也无法读取。不过，这种模式存在一个经常被忽视的漏洞：用户必须信任消息应用程序会为每个联系人分发正确的公钥。
如果攻击者能够在将错误的公钥替换到消息应用程序的数据库中，他们就可以拦截原本发送给其他人的消息消息，而发送方对此毫不知情。
密钥透明度通过创建可审计的、只能附加的公钥日志来化解这一挑战，其概念类似于 TLS 证书的证书透明度。消息应用程序将其用户的公钥发布到透明度日志中，独立的第三方可以验证并确认该日志的构建是否正确且始终如一。2024 年 9 月，Cloudflare 宣布成为 WhatsApp 的密钥透明度审计员，为其提供独立的验证层，以帮助确保这款即时通讯应用程序的数十亿用户公钥分发的完整性。
如今，我们将在 Cloudflare Radar 中的新增密钥透明度部分发布密钥透明度审计数据。本部分将展示 Cloudflare 审计的密钥透明度日志，让研究人员、安全专家和感兴趣的用户能够了解这些关键系统的运行状况和活动。
新页面启动时会显示两个受监测的日志：WhatsApp 和 Facebook Messenger Transport。每个受监测的日志均以卡片形式显示，包含以下信息：
状态：指明日志是在线、正在初始化或已禁用。“在线”状态表示日志正在主动发布密钥更新到 Cloudflare 审核的纪元中。（纪元表示在特定时间应用于密钥目录的一组更新。）
最新签名的纪元：由消息服务日志发布并经 Cloudflare 确认的最新纪元。单击眼睛图标，用户可以查看 JSON 格式的完整纪元数据，包括纪元编号、时间戳、加密摘要和签名。
最新验证的纪元：Cloudflare 已验证的最新纪元。验证流程包括检查透明度日志数据结构从上一个纪元到当前纪元的转换是否代表有效的消息树转换，从而确保日志已正确构建。验证时间戳则指明 Cloudflare 完成审计的时间。
根：可审计密钥目录 (AKD) 树的当前根哈希值。此哈希值已加密处理，代表当前纪元密钥目录的完整状态。与纪元字段类似，用户单击即可查看审计员返回的完整 JSON 响应。
页面上显示的数据也可以通过 Key Transparency Auditor API 获取，该 API 提供审计员信息和命名空间的端点。
如果您想自行执行审计证明验证，可以按照我们审计密钥透明度博客文章中的说明进行操作。我们希望这些只是 Radar 的“密钥透明度”部分中发布的众多用例的首批用例。如果贵公司或组织对审计自己的公钥或相关基础设施感兴趣，请单击此处联系我们。
虽然边界网关协议 (BGP) 是互联网路由的骨干支柱，但其设计并无任何内置机制来验证传播路径的效果。长期以来，这种固有的信任导致全球网络容易遭受路由泄漏和劫持攻击，流量意外或恶意地绕过未经授权的网络。
虽然 RPKI 和 路由源授权 (ROAs) 已成功强化了路由来的安全性，但它们无法验证流量在网络之间选择的路径。自治系统提供商授权 (ASPA) 的作用恰好体现在这方面。ASPA 允许自治系统 (AS) 对列出已获授权可以向上游传播其路由的网络记录进行加密签名，从而扩展了 RPKI 的保护范围。通过验证客户到提供商的关系，ASPA 使系统能够自信地检测无效的路径公告并做出相应的反应。
虽然具体的 IETF 标准仍处于草案状态，但运营社群正在快速推进。区域互联网注册管理机构 (RIR)（例如 ARIN 和 RIPE NCC）的门户网站已经支持创建 ASPA 对象，而 OpenBGPD 和 BIRD 等主流路由软件技术栈也提供了验证逻辑。
为了更好地了解这项新兴标准的采用情况，我们在 Cloudflare Radar 的路由部分添加了全面的 RPKI ASPA 支持。通过在全球范围内跟踪这些记录，我们可以了解整个行业在路径验证方面取得的进展有多快速。
我们全新的 ASPA 部署视图让用户可以查看 ASPA 的采用率随时间推移的增长情况，并且能够根据 AS 注册情况，可视化五个区域互联网注册管理机构 (RIR) 的趋势。您可以查看自 2023 年 10 月 1 日以来所有 ASPA 条目的完整历史记录，或放大到特定日期范围，将采用率激增与行业事件（例如 ARIN 和 RIPE NCC 在线仪表板中推出 ASPA 功能）关联起来。
除了聚合趋势之外，我们还推出了精细化、可搜索的实时 ASPA 内容浏览器。此表格视图让用户可以检查 ASPA 记录的当前状态，按 AS 编号、AS 名称搜索，或筛选仅显示提供商或客户 ASN。这让网络运营商能够验证其记录是否已正确发布，并查看其他网络的配置。
我们还将 ASPA 数据直接集成到国家/地区路由页面中。现在，用户可以根据与本地注册的客户 ASN 关联的 ASPA 记录，跟踪不同地点在保护其基础设施方面的进展。
在单独的 AS 页面中，我们更新了“连接”部分。现在，在查看网络连接时，用户可能会看到“ASPA 已验证的提供商”的视觉指指示符。此注释确认存在授权该特定上游连接的 ASPA 记录，从而立即表明路由的完整性和可信度。
对于已经部署 ASPA 的 AS，我们现在会显示已授权的提供商 ASN 的完整列表及其详细信息。除了当前状态之外，Radar 还提供涉及该 AS 的 ASPA 活动的详细时间线。历史记录会区分由 AS 自身（“作为客户”）发起的更改，以及其他人创建的将其指定为提供商的记录（“作为提供商”），让用户能够立即识别何时建立或修改了特定的路由授权。
可见性是更广泛采用新兴路由安全协议（例如 ASPA）至关重要的第一步。通过公开这些数据，我们旨在帮助运营商部署保护措施，并协助研究人员跟踪互联网在构建更安全路由路径方面已取得的进展。对于需要将这些数据集成到自己的工作流程或进行更深入分析的用户，我们也以编程方式公开了这些指标。现在，用户可以利用 Cloudflare Radar API 中新引入的端点，访问 ASPA 内容快照、历史时间序列和详细的变更数据。
互联网安全技术持续发展，新的方法、协议和标准也不断涌现，以确保信息、应用程序和网络安全。Cloudflare Radar 中提供的安全数据和见解也将继续发展。上述新增部分旨在扩展 Cloudflare Radar 中现有的路由安全、透明度和后量子时代见解。
如果您在社交媒体上分享这些新的图表，请务必标记我们：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)。如果您有任何问题、意见或对希望我们在 Radar 中添加的数据有任何建议，您可以通过社交媒体或电子邮件联系我们。