通用面試：新協定為什麼應要求 TLS 1.3？

題目與使用情境

你要設計一個運行在 TCP 上的新應用層協定。產品希望首發時相容 TLS 1.2，安全團隊則希望只支援 TLS 1.3。請依據 RFC 9852 說明預設版本、握手失敗行為、舊客戶端遷移、後量子密碼準備，以及為什麼同一結論不能直接套到 DTLS。

面試官考察什麼

• 是否能區分新協定要求 TLS 1.3 與既有服務遷移到 TLS 1.3 的問題邊界。
• 能否解釋 TLS 1.3 對弱密碼、重新協商、握手隱私和設定複雜度的改善，而不是只背版本號。
• 是否會把版本協商、客戶端能力、可觀測性、回滾和相容成本寫成可執行的發布方案。
• 是否理解 RFC 9852 明確只針對 TLS，不適用於 DTLS，並能識別 QUIC 等協定的不同整合方式。

作答前的釐清問題

先確認協定運行在 TLS 還是 DTLS、是否需要 UDP、客戶端更新節奏、是否存在嵌入式裝置，以及威脅模型是否包含被動竊聽、降級和流量分析。再詢問是否需要代理、中間設備或長期離線升級。若協定是全新設計且使用 TLS，RFC 9852 的規範性要求是起點；若是既有協定，則需要單獨評估遷移和相容窗口。

30 秒回答框架

對於使用 TLS 的全新協定，我會把 TLS 1.3 設為最低且預設版本，客戶端和服務端無法達成 TLS 1.3 時終止連線。RFC 9852 允許因部署現實把 TLS 1.2 保留為額外的非預設選項，但新規格應優先 TLS 1.3。遷移方案包括能力探測、分階段客戶端升級、握手失敗可診斷性和明確截止日期；PQC 採用可插拔金鑰協商。這個結論不直接適用於 DTLS，因為 RFC 9852 明確說 DTLS 1.3 的部署還不夠廣泛。

分步驟深入解答

1. 先劃清規格範圍

RFC 9852 針對新協定使用 TLS 的情境，要求協定假設 TLS 1.3 可用並要求使用它。它更新 RFC 9325 的建議，但不改變 DTLS 版本要求。若協定使用 QUIC，應遵循 QUIC 自身規定的 TLS 1.3 整合，而不是把 TCP 應用層握手步驟直接複製過去。

2. 說明 TLS 1.3 的安全收益

TLS 1.3 移除了多種弱密碼和複雜協商路徑，並加密更多握手內容，減少隱私暴露。TLS 1.2 並非一定不安全，但需要關閉重新協商、舊金鑰交換和脆弱套件等額外設定；新協定強制 TLS 1.3 可以把安全基線寫進協定，而不是依賴每個部署者手工拼裝。

3. 定義版本協商和失敗行為

協定應把 TLS 最低版本寫入規格，並要求客戶端至少提供 TLS 1.3。服務端選擇雙方支援的最高版本；若新協定只允許 TLS 1.3，則沒有共同版本時必須終止連線並返回可觀測的錯誤類別，不能靜默降級到明文或 TLS 1.2。日誌不能記錄金鑰或敏感負載，只記錄版本、錯誤類別和對端能力摘要。

4. 處理 TLS 1.2 的現實相容

如果硬體或客戶升級週期使 TLS 1.2 無法立即移除，可以把它定義為額外的非預設選項，明確適用版本、截止日期和風險接受人。預設設定、範例程式碼和測試矩陣都必須使用 TLS 1.3；TLS 1.2 路徑需要單獨監控、限流、禁用弱套件並提供退出開關，不能讓相容選項成為永久預設。

5. 規劃客戶端遷移

先統計客戶端版本、函式庫能力和失敗原因，再分階段發布：新增客戶端只實作 TLS 1.3，舊客戶端升級函式庫和設定，服務端先觀察協商比例，最後關閉 TLS 1.2。把握手失敗映射到可行動的更新提示，準備灰度、回滾和支援流程；不要用一次性全量切換掩蓋長尾裝置。

6. 納入 PQC 與運行治理

RFC 9852 指出 TLS 1.3 是後量子密碼持續標準化的承載基礎。協定設計應避免把金鑰交換演算法寫死，保留升級和混合方案的擴充點。上線後監控版本分布、握手延遲、失敗率、降級嘗試和憑證錯誤，定期更新密碼函式庫並透過互通測試驗證實作差異。

高品質示範回答

我會先確認這是新建的 TCP 應用層協定，而不是既有協定遷移。對使用 TLS 的新協定，我依據 RFC 9852 把 TLS 1.3 設為最低版本和預設版本；雙方無法協商 TLS 1.3 就終止連線。TLS 1.2 可以因部署現實作為額外非預設選項，但規格、範例和測試必須以 TLS 1.3 為主，並寫明風險、監控和關閉日期。TLS 1.3 透過移除弱密碼路徑、減少複雜設定和加密更多握手內容提供更一致的安全與隱私基線。遷移時統計客戶端能力，先升級函式庫和嵌入式裝置，再灰度關閉 TLS 1.2；錯誤只暴露可行動的版本類別，不洩露金鑰或負載。金鑰交換保持可擴充以便接入 PQC，並透過版本分布、失敗率、握手延遲和互通測試治理。RFC 9852 明確不適用於 DTLS，因此若協定改用 UDP，我會單獨評估 DTLS 版本和部署狀態。

常見錯誤

• 把 TLS 1.2 一律描述為不安全，忽略 RFC 9852 對新協定和既有部署的範圍區分。
• 允許服務端靜默降級到 TLS 1.2、明文或自訂加密。
• 把 TLS 的結論直接套用到 DTLS，或忽略 QUIC 的 TLS 整合規則。
• 只寫升級客戶端，沒有能力盤點、失敗可觀測性、灰度和截止日期。
• 把密碼套件寫死，導致未來 PQC 或函式庫升級無法演進。

追問及應對

為什麼 TLS 1.2 只能是非預設選項？

RFC 9852 的理由是 TLS 1.3 已廣泛部署，並改善了 TLS 1.2 的安全與隱私缺陷。保留 TLS 1.2 只能服務於明確的部署約束，不能讓新協定的安全基線取決於各實作者是否正確關閉舊路徑。

什麼時候可以刪除 TLS 1.2？

當客戶端版本、函式庫支援和關鍵地區的協商比例達到預設門檻，並完成公告、灰度和支援準備後刪除。保留可觀測窗口，確認失敗主要來自可升級客戶端，而不是未知的關鍵裝置。

如果協定改成 UDP，是否仍然只要求 TLS 1.3？

不能直接沿用。RFC 9852 明確只針對 TLS，不針對 DTLS；UDP 方案要依據 DTLS 的實際部署、協定整合和風險單獨制定版本要求。QUIC 也應遵循自身要求 TLS 1.3 的規格。