2025 年 1 月 23 日，Cloudflare 透過其漏洞懸賞活動獲悉 Cloudflare Mutual TLS (mTLS) 實作中的一個漏洞。
此漏洞影響了使用 mTLS 的客戶，並涉及我們的工作階段繼續執行處理中的一個缺陷。Cloudflare 的調查顯示，沒有任何證據表明漏洞正在被積極利用。該漏洞的追蹤編號為 CVE-2025-23419，Cloudflare 在收到通知後 32 小時內緩解了該漏洞。結合使用 Cloudflare 的 API Shield 和驗證核發者之主體金鑰識別碼 (SKI) 的 WAF 自訂規則的客戶不會受到攻擊。身分驗證、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 交握。
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 將不再允許再續快取用戶端憑證及其驗證狀態的工作階段。
我們正在尋找方法，讓 mTLS 客戶能夠重新擁有 TLS 工作階段繼續執行所帶來的效能改進。
進一步強化
客戶可以使用 Cloudflare 的 Transform Rules、記錄和防火牆功能，進一步強化其 mTLS 設定，並新增增強的記錄來偵測未來的問題。
雖然 Cloudflare 已透過停用 mTLS 連線的工作階段繼續執行來緩解該問題，但客戶可能希望在其源站實作額外的監控，以執行更嚴格的驗證原則。所有使用 mTLS 的客戶也可以使用我們的 Managed Transforms 產品啟用其他要求標頭。啟用此功能後，我們可以將其他中繼資料以及用於連線的用戶端憑證的詳細資料傳遞到您的源站。
啟用此功能後，您可以看到正在對要求使用 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 Log 產品，透過記錄自訂欄位功能新增這些標頭。例如：
這會將以下資訊新增至 Cloudflare Logs。
"RequestHeaders": {
"cf-cert-issuer-ski": "A5AC554235DBA6D963B9CDE0185CFAD6E3F55E8F",
"cf-cert-sha256": "528a65ce428287e91077e4a79ed788015b598deedd53f17099c313e6dfbc87ea"
},
已經在源站或透過 Cloudflare Logs 記錄此資訊的客戶可以追溯檢查未觸發任何安全原則的意外憑證雜湊或核發者。
使用者還可以在其 WAF 自訂規則中使用此資訊來執行其他檢查。例如，檢查核發者的 SKI 可以提供額外的安全層。
啟用此額外檢查的客戶不容易受到攻擊。
結論
我們衷心感謝安全研究人員透過我們的 HackerOne 漏洞懸賞計畫負責任地披露此問題，讓我們能夠識別並緩解該漏洞。歡迎研究人員社群進一步提交意見，以持續提高我們產品的安全性。
最後，我們想向 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 – 推出完成。漏洞已得到修復。