Cloudflare Radar 目前已提供廣泛的安全解析，涵蓋應用程式層與網路層攻擊、惡意電子郵件、數位憑證，以及網際網路路由等多個面向。
今天，我們進一步擴充這些功能。我們在 Radar 上推出多項新的安全相關資料集與工具：
我們正在擴展後量子 (PQ) 監測範圍，從原本僅限用戶端，現在進一步納入面向來源伺服器的連線。我們也發布了一個新工具，協助您檢查任何網站的後量子加密相容性。
Radar 上新增了「金鑰透明度」專區，提供一個公開儀表板，展示像 WhatsApp 這類端對端加密訊息服務的金鑰透明度記錄的即時驗證狀態，清楚顯示每筆記錄最後由 Cloudflare 的稽核員簽署和驗證的時間。該頁面作為一個透明的介面，任何人都可以在此監控公開金鑰分發的完整性，並透過 API 獨立驗證我們稽核員的證明。
路由安全解析持續擴充，新增了關於 ASPA 部署的全球、國家/地區和網路層級資訊。ASPA 是一種新興標準，有助於偵測並防止 BGP 路由洩漏。
自 2024 年 4 月起，我們便在 Cloudflare Radar 上追蹤用戶端對後量子加密支援的整體成長情況，記錄了這項技術從 2024 年初低於 3% 的支援率，到 2026 年 2 月成長至超過 60% 的全球普及歷程。而在 2025 年 10 月，我們新增了一項功能，讓使用者能夠檢查其瀏覽器是否支援 X25519MLKEM768——這是一種混合型金鑰交換演算法，結合了傳統的 X25519 與 ML-KEM（一種由 NIST 標準化的晶格後量子方案）。此演算法能同時抵禦傳統電腦與量子電腦的攻擊。
然而，僅關注用戶端到 Cloudflare 連線的後量子加密支援並不全面。
對於不在我們 CDN 快取中的內容，或是無法快取的內容，Cloudflare 的邊緣伺服器會與客戶的來源伺服器建立獨立連線以進行擷取。為了加速這些面向來源伺服器的擷取請求邁向量子安全加密的過渡，我們先前推出了一款 API，允許客戶選擇優先使用後量子連線。今天，我們進一步在 Radar 上公開來源伺服器的後量子相容性資訊。
Radar 上新增的「源站後量子支援」圖表，展示了支援 X25519MLKEM768 的客戶來源伺服器佔比。此數據源自我們的自動化 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 連接埠）。按一下「測試」後，結果會顯示一個標籤，指出後量子支援狀態以及最終協商的 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。每個受監控的記錄會以卡片形式呈現，包含以下資訊：
狀態：表明記錄是處於「在線」、「初始化中」或「已停用」。「在線」狀態意味著該記錄正積極地將金鑰更新發布到各個「週期 (epoch)」中，以供 Cloudflare 稽核。（「週期」代表在特定時間點套用至金鑰目錄的一組更新。）
最後簽署週期：由通訊服務的記錄發佈且已由 Cloudflare 確認的最新週期。使用者可以點擊眼睛圖示，以 JSON 格式檢視完整的週期資料，包括週期編號、時間戳記、加密摘要和簽章。
最後驗證週期：Cloudflare 已完成驗證的最新週期。驗證過程包括檢查透明度記錄的資料結構從前一個週期到當前週期的轉變，是否代表一個有效的樹狀結構轉換——以確保記錄被正確建構。驗證時間戳記則標示 Cloudflare 完成稽核的時間。
根：目前可稽核金鑰目錄 (AKD) 樹的根雜湊值。此雜湊值以密碼學方式代表了當前週期金鑰目錄的完整狀態。與週期欄位相同，使用者可以點擊以檢視來自稽核員的完整 JSON 回應。
頁面上顯示的資料也可透過金鑰透明度稽核員 API 取得，該 API 提供用於查詢稽核員資訊和各個命名空間的端點。
如果您想自行執行稽核證明的驗證，可以依照我們《稽核金鑰透明度》」部落格文章中的說明進行操作。我們希望這些用例只是我們在 Radar 的「金鑰透明度」專區中發布的眾多用例的開端。如果您的公司或組織有興趣針對您的公開金鑰或相關基礎架構進行稽核，可以透過此處與我們聯繫。
雖然邊界閘道器通訊協定 (BGP) 是網際網路路由的骨幹，但其設計之初並未內建驗證其傳播路徑有效性的機制。這種先天信任使得全球網路長期以來都容易遭受路由洩漏和劫持的風險，導致流量意外或惡意地被導向未經授權的網路。
儘管 RPKI 和路由來源授權 (ROA) 已成功強化了路由的來源驗證，但它們無法驗證流量在網路之間傳輸所經過的路徑。這時，ASPA（自治系統提供者授權）便派上用場了。ASPA 擴展了 RPKI 的保護範圍，它允許一個自發系統 (AS) 以密碼學方式簽署一份記錄，列出被授權向上游傳播其路由的網路。透過驗證這些客戶對提供者的關係，ASPA 使系統能夠自信地偵測無效的路徑宣告並做出相應反應。
雖然具體的 IETF 標準仍在草案階段，但營運社群的行動相當迅速。支援建立 ASPA 物件的工具已進駐 ARIN 和 RIPE NCC 等區域網際網路註冊管理機構 (RIR) 的入口網站，而其驗證邏輯也已在 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 上新增的資料類型建議，歡迎透過社群媒體或電子郵件與我們聯繫。