新聞

後量子密碼學（PQC）導入TLS後，前後端部署出現明顯落差。根據網路基礎架構業者Cloudflare的統計，截至9月7日，一般使用者送往其內容傳遞網路（CDN）的HTTPS請求流量中，約7成已採用PQC混合式金鑰建立機制，但客戶來源伺服器支援比例僅約1成，顯示量子安全加密能力可能尚未涵蓋完整傳輸路徑。

主流瀏覽器已普遍支援混合式金鑰建立機制，在TLS 1.3連線中結合傳統橢圓曲線Diffie-Hellman（ECDH）與模組格基式金鑰封裝機制（ML-KEM）。這種做法可降低攻擊者先攔截並保存加密資料，未來再利用量子電腦破解傳統金鑰建立機制後加以解密的風險。

問題在於，瀏覽器到CDN的連線即使已採用PQC，CDN連往來源伺服器的後端連線仍可能使用傳統金鑰建立方式。因此，前端連線支援PQC，不代表從使用者到來源伺服器的整段傳輸路徑都具備量子安全加密能力。

採用混合式金鑰建立機制也會增加TLS連線建立時的資料傳輸量。網路安全業者Red Sift整理相關資料指出，TLS交握時用戶端與伺服器端傳輸的資料量各增加約1,100位元組；Google先前則觀察到，桌面版Chrome的TLS交握延遲中位數增加約4%。這些額外負擔主要來自TLS連線建立時需要交換更多資料，密碼學運算增加的影響相對較小。

企業進行PQC轉型時，除了確認前端TLS連線的支援情況，也需要將來源伺服器與後端TLS連線納入盤點，避免前後端支援程度不同，導致量子安全加密能力只涵蓋部分傳輸路徑。