題幹與適用場景
一個企業服務希望讓持有授權金鑰的客戶端存取特定資源，同時不讓未驗證客戶端透過 401 或 challenge 探測出資源存在。團隊考慮 IETF RFC 9729（2025 年 2 月，Standards Track），該方案用 TLS keying material exporter 產生與連線綁定的簽章輸入，客戶端透過 Authorization: Concealed 傳送證明。
請設計客戶端、邊緣閘道和來源站的部署，說明 48 位元組匯出結果、驗證參數、TLS 版本限制、連線複用、金鑰撤銷、舊客戶端回退和上線驗證。RFC 9729 的 2026 年已驗證勘誤必須納入實作稽核。
面試官考察點
面試官看重你能否解釋「隱藏驗證能力」與「保證請求新鮮度」是兩個不同目標：RFC 9729 不發送 challenge，但證明的新鮮度不超過底層 TLS 連線生命週期。
強回答還會涵蓋前端閘道如何安全轉發 Concealed-Auth-Export、金鑰不可跨協定複用、HTTP/2/3 多路複用隔離、撤銷快取一致性、回退路徑和誤設定診斷，而不是只背出幾個 header 名稱。
回答前需要澄清的問題
- 客戶端金鑰由誰簽發、每個 origin 是否獨立，是否支援短期金鑰？
- 閘道和來源站是否拆分，兩者如何傳遞 TLS exporter 輸出？
- 資源存取需要連線級新鮮度還是每個請求級新鮮度？
- 舊客戶端只支援 TLS 1.2 時是否協商 Extended Master Secret？
- 授權撤銷需要秒級生效，還是允許快取視窗？
30 秒回答框架
「我會先按 origin 和 realm 建立公鑰目錄，客戶端在 TLS 連線上用 RFC 9729 指定的 exporter 計算 48 位元組輸出並簽章，閘道只解析和轉發合規參數，來源站負責最終驗簽和授權。TLS 1.3 預設滿足綁定要求，TLS 1.2 必須確認 Extended Master Secret，否則按未驗證處理。金鑰輪換採雙讀單寫和短快取，撤銷優先於快取；連線級證明不能冒充請求級新鮮度。灰度期間記錄參數解析、驗簽、撤銷和回退原因，異常時關閉新 scheme 而不暴露資源狀態。」
分步驟深入解答
先建立金鑰與 origin 目錄
伺服器為每個 origin 維護 key ID 到公鑰、演算法、realm、簽發時間和撤銷狀態的映射。客戶端私鑰只用於 Concealed 方案，不能複用到其他協定；RFC 9729 用固定簽名前綴降低跨協定誤用風險，但金鑰隔離仍是部署責任。金鑰 ID 不應編碼使用者隱私，稽核日誌使用不可逆內部標識。
計算連線綁定的證明
客戶端必須使用 exporter label EXPORTER-HTTP-Concealed-Authentication、RFC 規定的上下文和 48 位元組輸出。前 32 位元組進入簽章輸入，後 16 位元組作為驗證值傳送；上下文包含演算法、key ID、公鑰、scheme、host、port 和 realm。任何欄位編碼不一致都會導致驗簽失敗，不能由伺服器「寬鬆解析」修復。
exported = TLS-Exporter(label, context, 48)
signature_input = exported[0:32] + domain_separation_prefix
verification = exported[32:48]
Authorization: Concealed k=..., a=..., s=..., p=..., v=...設計閘道與來源站邊界
單體來源站可以直接讀取 TLS exporter。閘道與來源站拆分時，閘道驗證參數格式並透過 Concealed-Auth-Export 傳遞 48 位元組 exporter 輸出；該欄位必須只在受信任的內部鏈路出現，不能由公網客戶端注入。來源站仍需檢查請求目標、演算法、key ID、公鑰和簽章，閘道驗過格式不等於授權成功。
執行 TLS 與協定約束
RFC 9729 要求 TLS 1.3，或 TLS 1.2 且協商 Extended Master Secret。否則伺服器必須把請求視為沒有驗證。HTTP/2 和 HTTP/3 的 TLS 綁定可以使用該機制，但連線級證明可能涵蓋同一連線上的多個請求；客戶端和閘道必須隔離不同安全上下文，避免跨租戶讀取 Authorization 標頭。
處理新鮮度、複用與重放
匯出器證明的新鮮度最多等於 TLS 連線壽命，並非每個 HTTP 請求獨立。若資源要求更短視窗，伺服器可要求客戶端建立新連線，例如透過連線關閉或 HTTP/3 GOAWAY，再結合短期 key ID 和伺服器時間策略。不要把 v 參數當作請求 nonce，也不要在不驗證 host、port、realm 的情況下接受同一簽章。
輪換、撤銷與回退
金鑰目錄採雙讀單寫：先發布新公鑰並允許舊 key ID 短時間驗證，再切換客戶端，最後撤銷舊 key。撤銷檢查應在授權決策前完成，快取必須有明確 TTL 和失效通道。舊客戶端可回退到既有驗證，但回退回應要保持外部狀態一致，不能用不同 401 文案洩露資源是否存在。
可觀測性與故障定位
分層統計參數解析失敗、TLS 不滿足、key ID 未知、公鑰不匹配、簽章失敗、撤銷命中、閘道轉發失敗和回退率。按 origin、客戶端版本、協定和演算法分組，但不要記錄私鑰、完整簽章或可關聯的使用者金鑰。勘誤稽核要覆蓋 RFC 9729 第 3.3 節上下文字串和第 4 節整數 ABNF，避免實作與修訂後規範不一致。
灰度與安全測試
先對一個 origin 和可撤銷的低權限資源開啟，驗證 TLS 1.3、TLS 1.2+EMS、HTTP/2、HTTP/3、閘道拆分和連線重建。注入錯誤 host、port、realm、演算法、key ID、匯出長度、重複 header、過期撤銷快取和跨租戶連線，確認均按未驗證處理。回滾只停止簽發新金鑰和接受新 scheme，保留舊目錄與稽核記錄，避免把失敗請求變成可探測的狀態差異。
高品質示範回答
「RFC 9729 是連線綁定的不可探測驗證，不是每請求 nonce。客戶端按規範構造 exporter context，得到 48 位元組輸出並用專用金鑰簽章；閘道只做參數解析和受信任的 exporter 轉發，來源站驗證 TLS 條件、目標欄位、key ID、公鑰、簽章、撤銷和授權。TLS 1.3 或 TLS 1.2+EMS 才能接受，否則按未驗證處理。金鑰按 origin 隔離、雙讀單寫輪換，短新鮮度需求透過重建連線實現。灰度監控解析、驗簽、撤銷和回退，回滾停止新 scheme 並保持外部錯誤形態一致。」
常見錯誤
- 把 exporter 當每請求 nonce → 長連線上的證明可複用 → 明確連線級新鮮度，必要時重建連線。
- 只在閘道驗簽 → 來源站可能信任偽造的內部標頭 → 來源站仍驗證上下文與授權。
- TLS 1.2 未確認 EMS 也接受 → exporter 綁定不足 → 不滿足條件按未驗證處理。
- 金鑰跨協定複用 → 跨協定簽章混淆 → 每個方案和 origin 使用獨立金鑰。
- 撤銷結果長時間快取 → 已撤銷客戶端繼續存取 → 明確 TTL、失效通道和優先級。
- 回退回傳不同資源錯誤 → 暴露資源是否存在 → 統一外部狀態，內部記錄原因。
追問及應對
追問一：為什麼不讓來源站主動發 challenge？
主動 challenge 會讓未驗證客戶端觀察到資源需要驗證，破壞不可探測目標。RFC 9729 透過 TLS exporter 取得與連線綁定的新鮮材料，客戶端可以主動傳送證明。
追問二：48 位元組為什麼拆成 32 和 16？
規範把前 32 位元組作為簽章輸入，後 16 位元組隨請求傳送以便伺服器確認 exporter 輸出正確。實作必須按位元組範圍處理，不能把整個 48 位元組直接當作 nonce。
追問三：閘道把 exporter 轉發給後端安全嗎？
只有在閘道到後端的受信任、完整性保護鏈路上才安全。公網客戶端可偽造同名標頭，因此閘道必須覆蓋或剝離外部值，後端還應校驗內部通道身分和欄位長度。
追問四：如何應對已建立連線上的金鑰撤銷？
撤銷檢查在每次授權決策執行，不能只在連線建立時檢查。若風險要求更強的新鮮度，可撤銷舊 key、傳送連線關閉訊號並要求客戶端用新 key 建立連線。