題干與適用場景
你的平台要逐步引入 TLS 1.3 混合金鑰交換，以應對長期機密風險。請設計遷移路線，並說明協商、相容舊端點、效能和回滾如何處理。
面試官考察點
- 是否理解混合交換把不同安全假設的多個演算法組合，目標是至少一個元件未被攻破時仍保持工作階段金鑰安全。
- 是否知道 RFC 9954 是 Informational，未指定具體後量子演算法，也不等同於完成標準化部署。
- 是否能設計
supported_groups協商、傳統回退、金鑰與憑證邊界及中間盒相容性。 - 是否量化 ClientHello 大小、CPU、握手延遲、失敗率和遙測，再決定擴大流量。
回答前需要釐清的問題
- 保護的是新連線、長生命週期資料，還是必須符合特定合規要求？
- 客戶端、伺服器、負載平衡器和中間盒的 TLS 版本與升級能力如何分布？
- 需要混合的是金鑰交換，還是也要遷移認證簽章演算法？
- 可接受的握手延遲、頻寬、CPU 上限和回滾視窗是多少？
30 秒回答框架
我會先建立端點能力矩陣和基線指標，再用灰度流量協商一個傳統加後量子元件的 NamedGroup。混合金鑰只涵蓋 TLS 1.3 金鑰交換，認證簽章另行規劃；不支援的端點安全回退到傳統群組。重點監控 ClientHello 大小、握手延遲、CPU、失敗和中間盒相容性。任何異常先降低混合群組優先級或關閉灰度，不刪除傳統路徑，直到資料證明可擴大。
分步驟深入解答
1. 划清 RFC 的承諾邊界
RFC 9954 提供 TLS 1.3 混合金鑰交換的構造，採用把多個元件組合成一個 NamedGroup 的方式；它是 Informational，不選擇具體後量子演算法，也不處理後量子認證。方案目標是最終共享秘密在至少一個元件安全時保持安全，但前提包括元件安全性、固定長度和正確實作。
2. 設計協商與相容路徑
混合組合透過 supported_groups 表示，客戶端按偏好傳送 key share，伺服器選擇一個群組。混合感知雙方建立混合秘密；只有一方感知時，在允許降級的前提下使用傳統群組。伺服器保留傳統群組和憑證鏈，按端點能力、區域和業務風險配置優先級，避免一次失敗變成全站不可用。
3. 評估效能與線上容量
後量子公鑰和密文可能比傳統值大，ClientHello 可能跨越單一網路封包，影響 MTU、握手延遲和邊緣裝置。壓測 CPU、記憶體、頻寬、P50/P95/P99 握手時間、重試和連線成功率，按行動端、舊代理和跨區域鏈路切片。不要只測密碼函式庫基準，要測真實 TLS 終止層和重連行為。
4. 遷移控制、監控與回滾
先在實驗環境驗證金鑰協商和互通，再按租戶或區域小比例灰度。記錄協商群組、降級原因、握手失敗、封包大小和資源成本，但不記錄金鑰材料。出現錯誤率、延遲或合規問題時，降低混合群組優先級或關閉開關，保留傳統路徑。定期更新演算法和實作評估，不能把一次成功握手當成長期安全證明。
高品質示範回答
我會把這當作協定遷移而非一次密碼套件切換。先盤點客戶端、伺服器、負載平衡器和中間盒能力，建立 TLS 1.3 基線。依據 RFC 9954，把傳統元件與後量子元件作為一個 NamedGroup 協商，混合只涵蓋金鑰交換，認證簽章單獨規劃；混合雙方使用混合秘密，舊端點在允許降級時使用傳統群組。灰度期間量測 ClientHello 大小、P95 握手延遲、CPU、失敗率和跨區域相容性，按端點類型切片。所有金鑰材料不進日誌，保留傳統路徑和快速開關；任何紅線觸發就回退並保留診斷，再根據資料擴大範圍。
常見錯誤
- 把 RFC 9954 Informational 當成已完成的統一部署標準。
- 以為混合金鑰交換自動解決了後量子認證簽章。
- 刪除傳統群組，導致舊客戶端或中間盒無法連線。
- 只測演算法吞吐，不測 ClientHello 大小、MTU、重連和邊緣裝置。
- 把後量子元件名稱硬編碼成所有環境都必須使用的選擇。
- 沒有協商群組、降級原因和握手失敗的遙測與回滾開關。
追問及應對
為什麼不直接只用後量子演算法？
元件可能較新，安全分析和生態支援仍在演進；混合方案保留傳統假設，同時提供面向長期機密的過渡路徑。最終選擇應基於目標威脅、演算法成熟度和合規要求。
混合金鑰如何進入 TLS 1.3 金鑰排程？
每個元件產生共享秘密，按組合定義串接後作為 TLS 1.3 金鑰排程的輸入。組合必須固定長度並使用獨立隨機性，具體實作遵循所選 NamedGroup 規範。
如何防止相容性回退被濫用？
記錄降級原因，區分能力不支援與握手異常；對高風險連線設定最小 TLS 版本和允許群組策略。灰度期間監控異常降級，逐步收緊策略但保留明確的業務回退視窗。