2025 年 1 月 23 日，Cloudflare 通过其漏洞悬赏计划收到一则通知，指出 Cloudflare mutual TLS (mTLS) 实施中存在一个漏洞。
漏洞影响了使用 mTLS 的客户，并且涉及 Cloudflare 会话恢复处理中的一个缺陷。Cloudflare 的调查显示，没有证据表明该漏洞正在被大肆利用。该漏洞的跟踪编号为 CVE-2025-23419，Cloudflare 在收到通知后的 32 小时内缓解了其带来的影响。使用 Cloudflare 的 API Shield 以及 WAF 自定义规则（验证颁发机构的使用者密钥标识符 (SKI)）的客户不会受到攻击。身份验证、IP 地址限制和设备态势评估等访问策略也不会受到攻击。
漏洞悬赏报告详细指出，拥有一个 Cloudflare 区域的有效 mTLS 证书的客户端，可以使用相同证书通过 mTLS 恢复与另一个 Cloudflare 区域的 TLS 会话，而无需使用第二个区域来对证书进行身份验证。
Cloudflare 客户可以通过包含自定义防火墙规则的 Cloudflare API Shield 和 Cloudflare Zero Trust 产品套件实施 mTLS。Cloudflare 与客户端建立 TLS 会话，将客户端证书转发到 Cloudflare 的防火墙或 Zero Trust 产品并在这些产品中执行客户策略。
mTLS 通过扩展标准 TLS 握手来运行，要求连接双方，也就是客户端与服务器，进行身份验证。在典型的 TLS 会话中，客户端连接到服务器，后者提供其 TLS 证书。客户端验证证书，验证成功后即会建立加密会话。但是，使用 mTLS 时，客户端也会提供自己的 TLS 证书，由服务器验证证书，然后建立完整连接。只有当两个证书都通过验证后，会话才会继续，从而确保双向信任。
mTLS 对于保护 API 通信很有用，因为它确保只有合法且经过身份验证的客户端才能与后端服务交互。与依赖凭证或令牌的传统身份验证机制不同，mTLS 要求拥有有效证书及其对应的私钥。
为提高 TLS 连接性能，Cloudflare 采用了会话恢复。会话恢复可加快握手过程，从而减少延迟和资源消耗。其核心理念是，客户端与服务器成功完成 TLS 握手后，未来的握手应该予以简化，但假设的前提条件是密码套件或 TLS 版本等基本参数保持不变。
有两种主要的会话恢复机制：会话 ID 和会话票证。使用会话 ID，服务器会存储会话上下文并将其与唯一的会话 ID 关联。当客户端重新连接并在其 ClientHello 消息中提供此会话 ID 时，服务器会检查缓存。如果会话仍然有效，则使用缓存状态恢复握手。
会话票证以无状态方式运行。服务器不存储会话数据，而是加密会话上下文，将其作为会话票证发送给客户端。在未来的连接中，客户端会在其 ClientHello 消息中添加此会话票证，然后服务器可以解密该票证以恢复会话，从而无需服务器维持会话状态。
恢复的 mTLS 会话利用之前建立的信任，让客户端可以重新连接到受保护的应用程序，无需重新启动 mTLS 握手流程。
然而，在 Cloudflare 的 mTLS 实施中，会话恢复引入了一种意外行为。BoringSSL（Cloudflare 使用的 TLS 库）会在会话中存储来自原始的完整 TLS 握手的客户端证书。当该会话恢复时，不会针对完整信任链重新验证客户端证书，并且会尊重原始握手的验证状态。为避免出现这种情况，BoringSSL 提供了一个 API，用于在应用程序定义的不同“上下文”之间划分会话缓存/票证。遗憾的是，Cloudflare 使用该 API 的方法不正确，导致 TLS 会话在本不应该恢复时得以恢复。
为了利用此漏洞，安全研究人员首先在 Cloudflare 上设置了两个区域，然后在 Cloudflare 代理后进行配置，启用了 mTLS。两个区域的域配置完毕后，研究人员使用有效的客户端证书对第一个区域进行身份验证，从而让 Cloudflare 能够发出针对该区域的 TLS 会话票证。
研究人员随后将 TLS 服务器名称指示 (SNI) 和 HTTP 主机标头从第一个区域（其已通过身份验证）更改为第二个区域（其尚未通过身份验证）。然后，研究人员在与第二个受 Cloudflare 保护的 mTLS 区域握手时，提供了会话票证。这导致 Cloudflare 恢复与第二个区域的会话并将缓存客户端证书的验证状态报告为成功，从而绕过了启动会话通常所需的 mTLS 身份验证。
如果您在 API Shield 或访问策略中使用了其他验证方法，例如，检查颁发机构的 SKI、验证身份、IP 地址限制或设备态势评估，这些控制措施将继续按预期发挥作用。但是，由于 TLS 会话恢复的问题，mTLS 检查错误地返回了验证通过的结果，而没有重新评估完整的证书链。
我们已经为所有启用了 mTLS 的客户禁用 TLS 会话恢复。因此，Cloudflare 将不再允许恢复那些缓存了客户端证书及其验证状态的会话。
我们正在探索通过 TLS 会话恢复，为 mTLS 客户带来性能改进的方法。
客户可以使用 Cloudflare 的转换规则、日志记录和防火墙功能，进一步强化其 mTLS 配置并添加增强日志记录功能来检测可能出现的问题。
虽然 Cloudflare 已通过禁用 mTLS 连接的会话恢复缓解了这个问题，但客户可能希望对其源服务器进行额外的监测，以实施更严格的身份验证策略。使用 mTLS 的所有客户还可以使用 Cloudflare 的托管转换产品，启用额外的请求标头。启用此功能后，Cloudflare 能够向客户源服务器传递额外的元数据，其中包含连接所使用的客户端证书的详细信息。
启用此功能后，您可以查看请求中使用 mTLS 的以下标头。
{
"headers": {
"Cf-Cert-Issuer-Dn": "CN=Taskstar Root CA,OU=Taskstar\\, Inc.,L=London,ST=London,C=UK",
"Cf-Cert-Issuer-Dn-Legacy": "/C=UK/ST=London/L=London/OU=Taskstar, Inc./CN=Taskstar Root CA",
"Cf-Cert-Issuer-Dn-Rfc2253": "CN=Taskstar Root CA,OU=Taskstar\\, Inc.,L=London,ST=London,C=UK",
"Cf-Cert-Issuer-Serial": "7AB07CC0D10C38A1B554C728F230C7AF0FF12345",
"Cf-Cert-Issuer-Ski": "A5AC554235DBA6D963B9CDE0185CFAD6E3F55E8F",
"Cf-Cert-Not-After": "Jul 29 10:26:00 2025 GMT",
"Cf-Cert-Not-Before": "Jul 29 10:26:00 2024 GMT",
"Cf-Cert-Presented": "true",
"Cf-Cert-Revoked": "false",
"Cf-Cert-Serial": "0A62670673BFBB5C9CA8EB686FA578FA111111B1B",
"Cf-Cert-Sha1": "64baa4691c061cd7a43b24bccb25545bf28f1111",
"Cf-Cert-Sha256": "528a65ce428287e91077e4a79ed788015b598deedd53f17099c313e6dfbc87ea",
"Cf-Cert-Ski": "8249CDB4EE69BEF35B80DA3448CB074B993A12A3",
"Cf-Cert-Subject-Dn": "CN=MB,OU=Taskstar Admins,O=Taskstar,L=London,ST=Essex,C=UK",
"Cf-Cert-Subject-Dn-Legacy": "/C=UK/ST=Essex/L=London/O=Taskstar/OU=Taskstar Admins/CN=MB ",
"Cf-Cert-Subject-Dn-Rfc2253": "CN=MB,OU=Taskstar Admins,O=Taskstar,L=London,ST=London,C=UK",
"Cf-Cert-Verified": "true",
"Cf-Client-Cert-Sha256": "083129c545d7311cd5c7a26aabe3b0fc76818495595cea92efe111150fd2da2",
}
}
Enterprise 客户也可以使用我们的 Cloudflare Logs 产品，通过 Logs 自定义字段功能来添加这些标头。例如：
这会将以下信息添加到 Cloudflare Logs。
"RequestHeaders": {
"cf-cert-issuer-ski": "A5AC554235DBA6D963B9CDE0185CFAD6E3F55E8F",
"cf-cert-sha256": "528a65ce428287e91077e4a79ed788015b598deedd53f17099c313e6dfbc87ea"
},
已记录此信息的客户（无论是在其源服务器上还是通过 Cloudflare Logs），可以追溯检查意外证书哈希值或未触发任何安全策略的证书颁发机构。
用户还能够在其 WAF 自定义规则中使用这些信息来进行附加检查。例如，检查颁发机构的 SKI 可以增加额外的安全保障。
启用了这项附加检查功能的客户不易遭受攻击。
我们衷心感谢通过 Cloudflare 的 HackerOne 漏洞悬赏计划负责任地披露这个问题的安全研究人员，让我们能够识别并缓解该漏洞。我们欢迎更多安全研究人员提交报告，以不断提高 Cloudflare 产品的安全性。
最后，我们想向那些受到 mTLS 漏洞影响的客户致歉。安全是 Cloudflare 一切工作的核心，对于该漏洞可能引发的担忧，我们深表歉意。我们已立即采取措施修补该漏洞，并且部署了额外的保护措施，以防今后出现类似问题。
所有时间戳均采用世界协调时间 (UTC) 格式
2025-01-23 15:40 – Cloudflare 收到了关于 mutual TLS 和会话恢复使用中存在漏洞的通知。
2025-01-23 16:02 至 21:06 – Cloudflare 验证了 mutual TLS 漏洞并准备了一个禁用 mutual TLS 会话恢复的版本。
2025-01-23 21:26 – Cloudflare 开始实施补救措施。
2025-01-24 20:15 – 完成了补救措施。修复了漏洞。