Cloudflare 資料揭示量子安全 TLS 部署落差

根據 Cloudflare 於 9 月 7 日公布的統計，約 70% 的使用者 HTTPS 請求在抵達其 CDN 時已採用 後量子密碼學 (PQC) 混合式金鑰建立機制，但來源伺服器端的支援度僅剩 約 10%。此差距顯示，量子安全加密仍未覆蓋完整的傳輸路徑，前後端部署不一致可能留下資安盲點。

為何前端已普及而後端仍落後？

混合式金鑰建立：在 TLS 1.3 連線中，同時使用傳統的 橢圓曲線 Diffie‑Hellman (ECDH) 與 模組格基式金鑰封裝機制 (ML‑KEM)。此做法能降低攻擊者在未來利用量子電腦破解傳統金鑰後的解密風險。
瀏覽器支援：主流瀏覽器已內建此混合機制，使用者端與 CDN 的加密已具備量子抗性。
後端連線瓶頸：CDN 與來源伺服器之間的後端 TLS 仍多採用傳統金鑰建立方式，未同步升級至 PQC，導致從使用者到最終伺服器的完整路徑仍可能被量子攻擊者截取後解密。

性能與成本的雙重挑戰

資料量增加：Red Sift 的分析指出，TLS 交握時雙方各需額外傳送約 1,100 位元組。
延遲影響：Google 觀測到桌面版 Chrome 的 TLS 交握延遲中位數上升約 4%。
運算負擔：實際的密碼學運算開銷相對較小，主要瓶頸在於額外的資料交換。

企業轉型的關鍵檢視點

全路徑盤點：不僅要確認前端（瀏覽器 ↔ CDN）的 PQC 支援，亦必須檢查 CDN ↔ 來源伺服器的後端 TLS。
升級計畫：將支援 ML‑KEM 的伺服器軟體與硬體佈署至來源端，避免前後端加密能力不對稱。
效能測試：在導入混合式金鑰前，先行評估額外的傳輸量與延遲對業務服務的影響，做好容量規劃。

未來展望

隨著量子電腦技術逐步成熟，全鏈路量子安全將成為資安防護的基本需求。業界若能同步推動前端與後端的 PQC 部署，才能真正實現「從使用者到來源伺服器」的端到端防護。對於企業而言，現在正是檢視 TLS 全路徑、制定量子抗性升級藍圖的最佳時機。

提醒：持續關注資安日報與資安週報的免費電子報，掌握全球與臺灣最新資安動態，確保您的組織不被量子時代的資安挑戰所落下。