2026 年 RFC 10024 落地後，ML-KEM TLS 1.3 怎麼驗證？

設定檔已加入 ML-KEM 群組名稱，但握手輸出看不出實際協商了什麼。

最快的處理方式：依 RFC 10024 在隔離測試環境確認 TLS 1.3 實際協商結果，再測新舊客戶端相容性與失敗回退；通過後分批推廣，不要只憑設定項判定已啟用。RFC 10024 定義的是結合 ML-KEM 與傳統密鑰交換的混合機制，不代表所有 TLS 加密及簽章環節都已完成後量子遷移。

本文適合負責 TLS 1.3 客戶端或伺服器升級的工程師，用來安排聯調與驗收。
負責發布、回滾的 SRE，可用檢查點整理變更風險。
維護安全測試環境的團隊，則可據此規劃可重現的後量子密碼測試。

最後更新於 2026-10-01；標準狀態核對自 IETF RFC 10024，設定與結果查核方式參照 OpenSSL 官方群組設定及協商結果文件。

先釐清 RFC 10024 涵蓋什麼，再訂測試邊界

RFC 10024 已作為 IETF Proposed Standard 發布，定義 TLS 1.3 的後量子與傳統密鑰交換混合機制。以 X25519MLKEM768 為例，名稱對應 X25519 與 ML-KEM-768 的組合；這是密鑰協商層的改動，不是把整個 TLS 連線中的所有密碼功能一次換成後量子方案。細節應以RFC 10024 的群組定義及RFC 9954 的混合密鑰交換框架為準。

TLS 1.3 的協定定義另見RFC 8446；ML-KEM 的演算法標準則見NIST FIPS 203。兩者各自回答不同問題：TLS 標準規範握手，FIPS 203 規範 ML-KEM。不能因為一端支援 ML-KEM，就推論憑證簽章、其他演算法或整條網路路徑也已完成後量子遷移。

開始前，先列出實際握手經過的元件，而非只盤點應用程式：

• 客戶端與伺服器各自使用的 TLS 程式庫、版本及支援群組。
• TLS 終止位置：應用程式、反向代理、負載平衡器或其他中介設備。
• 測試是否經過與正式環境相同的代理、檢查設備及網路路徑。
• 對應程式庫官方文件中，群組設定方式、協商結果查詢方式及已知限制。

RFC 定義機制，不會替特定產品確認支援版本、預設設定或互通性。每項能力都要回到相應客戶端、伺服器與 TLS 程式庫的官方文件核實；不要把「設定格式可接受」當成「實際握手已使用」。

準備測試組合，讓端點與網路路徑都可辨識

先固定測試條件，否則握手結果即使不同，也難以判斷問題出在客戶端、伺服器或中間設備。建議為每次測試記錄端點角色、實作與版本、TLS 設定、網路路徑，以及用來觀察握手的診斷方式。若環境中有多個 TLS 終止點，也要確認觀察到的是哪一段連線，而非只記錄最外層用戶端到服務入口的結果。

下表把測試組合與決策目的放在一起；「舊版」代表待驗證的既有客戶端或元件，不預設它支援或不支援新群組。

測試組合	要核對的觀察結果	可作出的判斷
支援新群組的客戶端與測試伺服器	握手診斷是否顯示預期協商群組	確認正向路徑，不代表正式網路已相容
舊版客戶端與同一伺服器	是否能按預期建立連線，協商結果為何	評估既有客戶端的影響範圍
經代理或負載平衡設備的連線	前後兩段連線各自的終止點與結果	找出設備是否終止或改變了握手
模擬協商失敗或不支援的情況	失敗階段、錯誤資訊及是否走預期回退	判斷回退可控性及監控是否足夠

這份矩陣不是所有產品的相容性結論。請按照正式環境中存在的客戶端種類、中介設備與連線路徑調整；如果無法取得某一段握手的觀察資料，就先補上記錄能力，再把結果納入發布判斷。可先參考本站說明中心確認測試環境資訊與服務範圍，但不能以服務介紹取代實際端點的官方支援文件。

檢查握手輸出，確認實際協商群組

TLS 1.3 怎麼確認實際協商了 X25519MLKEM768？

驗證重點不是設定檔裡有沒有 X25519MLKEM768，而是該次握手輸出是否能辨識實際協商的群組。先使用 TLS 程式庫或支援的診斷工具取得握手結果，再確認工具呈現的是本次連線的協商值，而不是本機可用群組清單。若使用 OpenSSL，應按其官方文件確認群組設定與結果查詢介面；不同版本及呼叫方式須以相應版本文件為準，不能將其他實作的指令直接套用。

一次測試至少要能回答：連線是否成功、使用哪個 TLS 版本、協商結果是否為預期群組，以及結果來自哪個用戶端、伺服器與網路路徑。只看到 TLS 1.3 已建立，不能證明使用了混合密鑰協商；只看到用戶端宣告支援，也不能證明伺服器選中了該群組。

RFC 10024 對 TLS 客戶端和伺服器分別意味著什麼？

對客戶端而言，要確認實作能提出目標群組，並能從握手結果驗證伺服器實際選擇；對伺服器而言，要確認它能按預期接受、選擇或拒絕相關協商，而不是只在設定介面顯示一個名稱。兩端由不同 TLS 程式庫終止連線時，必須分別核對各自官方文件，再以真實握手結果確認互通性。RFC 說明標準機制，不等於指定產品已在預設狀態啟用。

若診斷只顯示「連線成功」而沒有協商群組，這項測試不足以作為啟用證據；應先補足握手結果的觀察方式，再重新執行。

測試端與正式連線也要分開記錄。實驗環境顯示協商成功，只能證明該組端點及路徑可行；正式流量還可能經過不同版本的用戶端、代理或負載平衡器。不可將測試端的輸出標記成全網部署結果。

驗證相容、分片與失敗回退，再判斷能否擴大

啟用 ML-KEM 後怎麼檢查握手失敗或回退？

不要只做成功路徑。應分別測試不支援目標群組的客戶端、經中介設備的連線，以及預期會拒絕協商的情況；每次都記錄連線結果、錯誤階段、實際協商群組和回退路徑。若實作提供握手追蹤或協商結果 API，使用對應官方文件所述方式收集證據，避免以應用程式層的通用錯誤訊息推斷 TLS 握手在哪裡失敗。

相容性測試也要留意握手訊息尺寸與分片行為。較長的握手資料可能暴露網路路徑或中介設備的限制，因此要在接近正式環境的路徑觀察是否出現逾時、重設或握手中止。出現連線異常時，保留握手階段、協商結果、錯誤資訊與路徑差異；單次成功不能證明所有客戶端或所有路徑都相容。

後量子 TLS 上線前需要哪些相容性測試？

至少覆蓋新舊客戶端、伺服器端支援情況、代理或負載平衡設備，以及協商失敗後的回退與監控。每個組合要有可重複的測試條件和判定結果；如果無法從輸出分辨回退前後的協商狀態，就先補足觀測，再決定是否擴大流量。

可依序勾選以下檢查項目：

• [ ] 已核對客戶端、伺服器及中介設備的 TLS 程式庫與版本文件。
• [ ] 能從該次握手輸出識別實際協商群組，不只查看設定值。
• [ ] 已測試既有客戶端與支援新群組的客戶端。
• [ ] 已覆蓋正式環境會經過的代理、負載平衡器及網路路徑。
• [ ] 已觀察握手失敗階段、錯誤記錄與預期回退行為。
• [ ] 已設定停止擴大及回滾條件，並確認發布人員能取得測試記錄。

推廣可採分批判斷：如果協商結果可辨識、代表性路徑均能重現、既有客戶端行為符合預期，且失敗時有明確回滾方法，才進入下一批；只要其中一項仍無法驗證，就先留在測試或小範圍發布。這是依測試證據作決策，不是對所有部署環境一律建議啟用。

整理可複核紀錄，讓發布與回滾有依據

驗收紀錄應讓另一位工程師能重做同一組測試。每筆至少記下測試時間、用戶端與伺服器實作及版本、TLS 設定、經過的中介設備、實際協商結果、錯誤發生階段與回退表現；同時保存足以重現結果的診斷輸出，並避免把憑證私鑰或其他機敏資料寫入紀錄。

回滾條件也要事先寫明，例如代表性既有客戶端出現無法接受的握手失敗、關鍵路徑無法辨識協商結果，或回退行為與預期不符。發布後持續觀察握手錯誤及協商分布；若問題只出現在特定代理或客戶端類別，應縮小變更範圍並按該路徑重測，而不是只憑少數成功樣本擴大發布。

目前依賴單一容器或共用測試端點，可能無法重現正式環境的作業系統差異；直接在正式伺服器改設定，也會增加回復成本，並讓測試結果受到線上流量干擾。若測試矩陣需要一個獨立的 macOS 客戶端端點，可評估 Zutcloud Mac mini 租用方案，但租用設備不代表已具備指定 TLS 程式庫或 ML-KEM 支援，仍須自行依官方文件驗證，也不能替代正式環境測試。若測試需要固定實體介面、長期穩定負載或組織自主管理硬體，應優先評估自購或既有測試設備；若只是短期補足隔離端點，再比較臨時租用與現有雲端環境的限制及成本。