題幹與適用場景
TLS 1.3 加密大部分握手內容，但傳統 ClientHello 可能暴露 SNI，使網路觀察者推斷目標服務。請說明 ECH 的協定角色、金鑰設定發布與失敗行為，並區分「隱藏 SNI」與「隱藏所有流量特徵」。
題目適合網路、安全、平台與通用協定職位。核心能力是 TLS 握手與隱私邊界，因此歸為 general。
面試官考察點
第一，是否理解外層與內層 ClientHello。ClientHelloOuter 提供相容外觀，真正目標資訊放在由伺服器設定公鑰加密的 ClientHelloInner。
第二，是否理解設定發布。客戶端需要包含公鑰與演算法中繼資料的 ECHConfig；設定可透過 DNS SVCB/HTTPS 記錄等方式取得，但發布要考慮真實性與新鮮度。
第三，是否知道 ECH 不是端到端匿名。DNS、IP、流量時序、憑證與未啟用 ECH 的路徑仍可能洩漏資訊。
第四，是否能解釋失敗回退。ECH 不可用時客戶端可能傳送普通 ClientHello 或重試，策略不能把錯誤設定當成成功隱私保護。
第五，是否能設計可觀測驗證。應檢查握手擴充、客戶端與邊緣日誌、設定命中率和回退率，而不只看 HTTPS 成功。
回答前需要釐清的問題
- 客戶端、邊緣代理與 TLS 函式庫是否支援 RFC 9849？
- ECHConfig 透過哪種 DNS 記錄或設定管道發布，DNSSEC/加密 DNS 如何處理？
- 服務是否有共享前端與多個後端名稱？
- 失敗時允許明文 SNI 回退，還是必須硬失敗？
- 要保護的是網域、租戶名稱還是更廣泛的流量中繼資料？
- 觀測系統能否記錄 ECH 成功而不洩露內層名稱？
30 秒回答框架
「ECH 把真實目標放進 ClientHelloInner，使用伺服器發布的 ECHConfig 公鑰透過 HPKE 加密；ClientHelloOuter 維持握手相容性。設定可經 DNS SVCB/HTTPS 發布，但要驗證來源與新鮮度。ECH 失敗時按策略回退或硬失敗，不能把 TLS 成功當作隱私成功。驗證要結合握手擴充、邊緣指標、設定命中率與回退率，同時承認 DNS、IP 與流量模式仍可洩露。」
分步驟深入解答
第一步：區分兩個 ClientHello
客戶端建立 ClientHelloInner，放入真實 SNI 與希望隱藏的擴充；再生成 ClientHelloOuter 作為相容訊息。伺服器或邊緣端使用 ECHConfig 公鑰解密內層，無法解密時按協定處理失敗。
第二步：理解 HPKE 與設定
ECHConfig 包含版本、公鑰、密碼套件與伺服器中繼資料。客戶端使用 HPKE 保護 ClientHelloInner，伺服器持有對應私鑰。輪換要有重疊有效期、快取控制與撤銷策略，不能把公鑰寫死在客戶端。
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)第三步：討論 DNS 發布與真實性
ECHConfig 可透過 SVCB/HTTPS 記錄等機制發現。DNS 記錄需要評估新鮮度、快取與竄改風險；加密 DNS 只保護傳輸路徑的一部分，DNSSEC 與應用策略仍決定是否信任設定。
第四步：定義失敗與回退
伺服器無法解密、設定過期、GREASE 或擴充不相容時，客戶端可能重試或回退普通握手。產品策略要明確哪些網域允許回退，哪些隱私要求必須硬失敗，並記錄原因。回退不是 ECH 成功。
第五步：辨識仍會暴露的資訊
ECH 隱藏 ClientHello 的目標名稱，但 DNS 查詢、目標 IP、連線時間、封包大小、憑證與後續應用行為仍可能用於流量分析。安全目標應描述為減少特定握手中繼資料暴露，而非宣稱匿名。
第六步：設計部署與金鑰輪換
邊緣叢集部署私鑰時使用最小權限與稽核，設定發布支援新舊金鑰重疊。多區域快取需要一致版本與失效策略；金鑰洩露時撤銷設定、縮短 TTL 並觀察回退率。
第七步：建立端到端驗收
使用支援與不支援 ECH 的客戶端、不同 DNS 解析路徑與多個邊緣節點測試。記錄 ECH extension 是否協商、設定版本、解密失敗、回退率、握手延遲與連線錯誤。抓包驗證時不要把內層敏感名稱寫入日誌。
高品質示範回答
「ECH 是 TLS 握手擴充。客戶端把真實 SNI 放入 ClientHelloInner，用 ECHConfig 公鑰透過 HPKE 加密，再用 ClientHelloOuter 保持相容。ECHConfig 可經 SVCB/HTTPS 發現，需處理 DNS 真實性、快取與輪換。
部署時我會明確失敗策略：隱私要求高的入口硬失敗，允許相容的入口記錄並區分普通握手回退。觀測包括協商擴充、設定命中、解密失敗、回退率與握手延遲；同時說明 DNS、IP、憑證與流量特徵仍可能暴露。驗收涵蓋多客戶端、DNS 路徑與金鑰輪換。」
常見錯誤
- 說 ECH 隱藏所有流量 → DNS、IP 與時序仍可見 → 限定隱私目標。
- 把 ECHConfig 公鑰寫死 → 輪換與撤銷困難 → 使用可更新設定。
- 只看 HTTPS 成功 → 普通握手回退被誤算為成功 → 記錄擴充與回退原因。
- 忽略 DNS 竄改與陳舊快取 → 客戶端使用錯誤設定 → 評估真實性、TTL 與刷新。
- 把 Outer SNI 當真實目標 → 誤解相容外觀 → 區分 public name 與 inner SNI。
- 金鑰輪換無重疊 → 多區域客戶端間歇失敗 → 設計重疊窗口與失效策略。
- 日誌記錄內層名稱 → 觀測系統重新洩漏隱私 → 只記錄雜湊、版本與狀態。
- 忽略不支援客戶端 → 真實使用者無法連線 → 保留明確回退或硬失敗規則。
追問及應對
追問一：ECH 與 DoH/DoT 有什麼關係？
ECH 保護 TLS ClientHello，DoH/DoT 保護 DNS 傳輸；兩者處理不同階段，可以組合但互不取代。
追問二：為什麼需要 ClientHelloOuter？
它提供相容外觀，讓不理解 ECH 的中間設備仍能處理握手，同時把真實目標放進加密內層。
追問三：ECH 失敗時一定要回退嗎？
不一定。策略取決於隱私與可用性要求；高隱私入口可硬失敗，相容入口可回退但要可觀測與可計數。
追問四：如何驗證中間盒沒有破壞 ECH？
從客戶端、邊緣與伺服器分別記錄協商狀態，在不同代理鏈路比較成功率、回退率與握手錯誤。
追問五：金鑰洩露後怎麼辦？
撤銷或停止發布舊 ECHConfig，縮短快取 TTL，部署新金鑰並監控解密失敗與回退。已暴露的 ClientHello 無法事後恢復隱私。
追問六：ECH 是否隱藏憑證中的網域？
它主要隱藏握手中的目標名稱；憑證、DNS、IP 與應用資訊仍可能提供關聯線索，不能承諾完全隱藏網域。