如何确认域名正在使用后量子 TLS：从握手测试到 Cloudflare 日志监控

2026-09-29 19 预计阅读时间: 1 分钟
来源: blog.cloudflare.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

启用后量子能力只是第一步，更重要的问题是：真实用户访问域名时，是否真的协商到了后量子保护？Cloudflare 已将后量子加密的可见性加入 HTTP Analytics、Log Explorer 和 Logpush，让团队能够从实际流量出发，检查 TLS 1.3 连接的协商情况，而不再只依赖配置页面上的开关。

这里需要先澄清一个容易混淆的概念：TLS 1.3 并不自动等于后量子安全。当前重点通常是用后量子或混合密钥交换，降低攻击者“现在收集密文、未来用量子计算机解密”的风险。

为什么配置正确还不够

一次 TLS 握手能否使用后量子密钥交换，取决于多个环节：

  • 服务端或 CDN 边缘节点是否支持并启用了相应能力；
  • 客户端浏览器、运行时或 TLS 库是否支持相同的协商组；
  • 请求是否真的经过预期的 Cloudflare 代理链路；
  • 中间代理、企业网关或旧版客户端是否限制了握手能力；
  • 不同主机名、区域和客户端版本是否表现一致。

因此，单次测试成功不能证明全部流量都受到保护；同样，日志中后量子连接比例较低，也不一定意味着服务端配置失败，可能只是大量客户端尚不支持。

Cloudflare 将相关信息暴露在三个不同层次：

  • HTTP Analytics：适合快速观察总体趋势与覆盖率；
  • Log Explorer：适合按主机名、客户端、路径或时间段排查异常；
  • Logpush：适合把数据送入对象存储、SIEM 或数据仓库，建立持续监控和告警。

先从客户端验证 TLS 握手

如果本机 OpenSSL 支持相应的混合 TLS 组，可以直接测试域名。下面以 X25519MLKEM768 为例；实际可用名称取决于 OpenSSL 版本和编译选项。

将 example.com 替换成你的域名：

DOMAIN=example.com

openssl s_client \
  -connect "${DOMAIN}:443" \
  -servername "${DOMAIN}" \
  -tls1_3 \
  -groups X25519MLKEM768 \
  </dev/null 2>&1 | grep -E \
  'Protocol|Cipher|Server Temp Key|Negotiated TLS1.3 group|Verification'

如果命令提示不支持该组，先检查 OpenSSL 版本及其可用的后量子算法：

openssl version -a
openssl list -kem-algorithms 2>/dev/null || true

需要注意，客户端命令只证明“这台测试机器与这个域名在这一次连接中”的结果。它不能替代生产流量分析，也不能覆盖其他浏览器、移动网络和企业代理。

用 Logpush 计算真实流量覆盖率

来源摘要没有给出具体日志字段名，因此下面采用一个可改造的示例。假设从 Logpush 导出的 NDJSON 中包含主机名，以及一个表示是否使用后量子 TLS 的布尔字段。运行前，应根据 Cloudflare 当前提供的字段定义替换字段名。

保存为 pq_coverage.py：

#!/usr/bin/env python3
import json
import os
import sys
from collections import defaultdict

HOST_FIELD = os.getenv("HOST_FIELD", "hostname")
PQ_FIELD = os.getenv("PQ_FIELD", "post_quantum")

stats = defaultdict(lambda: {"total": 0, "pq": 0})

for line in sys.stdin:
    line = line.strip()
    if not line:
        continue

    event = json.loads(line)
    host = str(event.get(HOST_FIELD, "unknown"))
    enabled = event.get(PQ_FIELD) is True

    stats[host]["total"] += 1
    stats[host]["pq"] += int(enabled)

print(f"{'hostname':40} {'pq':>10} {'total':>10} {'coverage':>10}")
for host, values in sorted(stats.items()):
    total = values["total"]
    pq = values["pq"]
    coverage = (pq / total * 100) if total else 0
    print(f"{host:40} {pq:10d} {total:10d} {coverage:9.2f}%")

可以先用模拟数据验证脚本：

cat > sample.ndjson <<'EOF'
{"hostname":"www.example.com","post_quantum":true}
{"hostname":"www.example.com","post_quantum":true}
{"hostname":"www.example.com","post_quantum":false}
{"hostname":"api.example.com","post_quantum":false}
EOF

python3 pq_coverage.py < sample.ndjson

接入真实 Logpush 数据时，可以通过环境变量映射实际字段名：

HOST_FIELD=ClientRequestHost \
PQ_FIELD=REPLACE_WITH_ACTUAL_PQ_FIELD \
python3 pq_coverage.py < cloudflare-http.ndjson

如果实际字段记录的是协商组名称而非布尔值，应修改判断逻辑，按 Cloudflare 字段文档中明确标识的后量子或混合组分类，不要仅凭字符串猜测。

把“是否启用”变成可运营指标

更有价值的监控方式不是只看全站平均值，而是按关键维度拆分：

  1. 按主机名统计：确认主站、API、静态资源域名和登录域名没有遗漏；
  2. 按客户端类型统计：识别旧浏览器、移动 SDK 或自动化客户端的兼容性缺口；
  3. 按国家和网络统计：发现特定区域、中间代理或运营商导致的协商差异；
  4. 按时间观察：在证书、TLS 策略或 CDN 配置变更后检查覆盖率是否突然下降；
  5. 保留传统 TLS 对照指标：同时关注 TLS 版本、握手失败率和延迟，避免为了提高后量子覆盖率而引入可用性问题。

告警阈值也不宜简单设为 100%。客户端能力不同，合理做法是先记录一段时间的基线，再针对支持后量子 TLS 的已知客户端观察异常下降。例如，某个主机名的覆盖率在配置发布后从 70% 降到 5%，比“未达到 100%”更值得立即调查。

上线前后的检查清单

  • 确认域名流量确实经过提供后量子 TLS 能力的 Cloudflare 链路；
  • 使用兼容客户端完成一次明确的握手测试；
  • 在 HTTP Analytics 中检查总体趋势；
  • 用 Log Explorer 定位未协商成功的客户端或主机名；
  • 将 Logpush 数据接入长期存储，并建立按主机名和客户端划分的覆盖率报表；
  • 同时监控握手错误、连接延迟和客户端兼容性；
  • 不要把“TLS 1.3 已启用”直接当作“后量子保护已生效”。

后量子 TLS 的落地不是一次配置任务，而是一个持续测量问题。配置页告诉你系统希望怎样工作，HTTP Analytics、Log Explorer 和 Logpush 则告诉你真实请求最终怎样完成了协商。

相关推荐