題目與背景
你維護一個需要長時間保持連線的管理面服務。建立連線時不希望所有用戶端都提交憑證，但高風險介面必須確認用戶端身分。請基於 TLS 1.3 設計握手後用戶端驗證，並說明它與雙向 TLS 初始握手的邊界。
面試官考察什麼
回答應把握手後驗證視為 TLS 1.3 的可選訊息流程，而非重新建立 TLS 連線。必須涵蓋用戶端在初始 ClientHello 宣告 post-handshake auth 能力、伺服器後續送出 CertificateRequest、用戶端回傳憑證鏈與 CertificateVerify、驗證失敗策略，以及 HTTP/2、HTTP/3 或應用協定如何將驗證結果綁定到請求。
先問清楚的澄清問題
驗證涵蓋範圍
確認是每條連線一次、每個高風險請求一次，還是按租戶切換。驗證結果保存太久會擴大撤銷窗口，過於頻繁則增加訊息與憑證驗證成本。
協定與實作邊界
確認連線承載 HTTP/1.1、HTTP/2、HTTP/3 或自訂協定，以及函式庫是否暴露握手後 API。驗證完成前，應用層必須阻止受保護操作，不能只依賴連線已建立。
失敗與撤銷策略
釐清憑證過期、未知 CA、簽章失敗或不支援能力時，是拒絕單一請求、關閉連線或降級為低權限工作階段，並確認 OCSP、短期憑證及撤銷清單來源。
30 秒回答框架
「TLS 1.3 握手後驗證要求用戶端在初始 ClientHello 送出 posthandshakeauth 擴充，伺服器之後用 CertificateRequest 發起驗證。用戶端回傳 Certificate、CertificateVerify 與 Finished，伺服器完成鏈、用途、簽章與撤銷檢查，再把已驗證身分綁定到後續請求。能力未協商或驗證失敗時不能假定成功；策略應拒絕受保護操作或關閉連線。」
深入解答步驟
第一步：協商能力並建立未驗證連線
用戶端在 ClientHello 宣告支援 post-handshake authentication。伺服器完成一般 TLS 1.3 握手，但把連線標記為「加密、尚未完成用戶端驗證」。未宣告能力的用戶端不能被臨時要求憑證。
第二步：按策略送出 CertificateRequest
高風險介面或租戶策略變更時，伺服器送出 CertificateRequest，包含簽章演算法和憑證發行者等限制。實作要把訊息納入 TLS 狀態機，避免與應用資料並行寫入時產生競態。
第三步：驗證用戶端回應
用戶端送出憑證鏈、CertificateVerify 和 Finished。伺服器驗證鏈、SAN、用途、簽章演算法、有效期及撤銷狀態，完成後才把身分寫入連線上下文。驗證前到達的敏感請求應排隊或拒絕。
第四步：處理失敗與重試
不支援能力、缺少憑證、簽章不符或憑證被撤銷時，按策略回傳錯誤、送出 TLS alert 或關閉連線。重試要有限次數與時間上限，不能把高風險請求自動降級為匿名請求。
第五步：考慮恢復、並行與連線遷移
工作階段恢復不會自動證明目前用戶端仍符合新的應用授權。HTTP/2 多路複用時，一條串流觸發驗證、其他串流可能同時送請求，必須定義阻塞邊界。HTTP/3 的 QUIC/TLS 整合也要確認函式庫支援。
第六步：設計憑證與密鑰運維
使用獨立用戶端 CA、短期憑證和可稽核信任庫更新。輪換 CA 時保留雙信任窗口與回滾方案；伺服器私鑰、信任庫和政策發布分開授權。
第七步：驗證與觀測
建立支援與不支援 posthandshakeauth 的用戶端矩陣，覆蓋成功、過期憑證、錯誤簽章、撤銷、逾時、並行串流及工作階段恢復。監控 CertificateRequest 發出率、成功率、失敗類別、驗證延遲、被拒請求和連線關閉。
高品質示例回答
我會把連線狀態拆成「加密但未驗證」和「用戶端已驗證」。用戶端必須在初始 ClientHello 宣告能力，伺服器才可後續送 CertificateRequest；用戶端回傳憑證鏈、CertificateVerify 和 Finished。伺服器完成 CA、SAN、用途、簽章、有效期和撤銷檢查後，才把身分綁定到高風險請求。能力未協商或驗證失敗時拒絕受保護操作，並用測試矩陣覆蓋並行、恢復與撤銷。
常見錯誤
- 錯誤： 連線建立成功就代表用戶端已驗證。→ 原因： TLS 加密和身分是兩個狀態。→ 改進： 明確維護未驗證與已驗證狀態。
- 錯誤： 任意客戶端都能被臨時要求憑證。→ 原因： 能力必須在初始 ClientHello 協商。→ 改進： 未協商者走低權限或重新連線策略。
- 錯誤： 驗證失敗後仍執行目前請求。→ 原因： 驗證訊息是非同步到達。→ 改進： 驗證完成前阻止高風險串流。
- 錯誤： 用舊連線身分套用新的租戶授權。→ 原因： 工作階段恢復和權限變更可能令舊狀態失效。→ 改進： 按授權版本重新評估。
追問與回答
追問 1：為什麼初始雙向 TLS 仍常見？
初始雙向 TLS 在握手結束前完成身分選擇，狀態簡單且相容性好，適合所有請求都必須驗證的連線。握手後驗證適合少數操作才需要額外身分的長連線，但狀態複雜度較高。
追問 2：握手後驗證能否取代應用層授權？
不能。它證明憑證私鑰持有者及其鏈，應用仍需將 SAN、租戶、角色、操作和撤銷狀態映射為授權決策。
追問 3：沒有憑證是否一定要斷線？
不一定。若政策允許，可保留低權限連線並拒絕受保護請求；若管理面要求全程驗證，則應回傳明確錯誤並關閉。選擇必須可稽核、可觀測。
追問 4：如何證明函式庫真的支援？
查閱對應版本 API 與互通測試，分別驗證擴充協商、CertificateRequest、錯誤憑證、並行串流和恢復連線。只有一個設定項不足以證明完整狀態機已實作。