題幹與適用場景
你負責一個由 CDN 承載的多網域服務。安全團隊發現即使啟用 TLS，網路觀察者仍能從 ClientHello 看見明文 SNI，並希望評估 Encrypted Client Hello（ECH）。請說明客戶端如何取得 ECH 設定、外層和內層 ClientHello 的職責、CDN 到來源站的邊界、相容舊客戶端的回退以及上線後的診斷指標。
面試官考察點
面試官要確認你理解 ECH 是 TLS 擴充，不是 VPN、DNS 加密或完整流量隱身。客戶端用伺服器發布的公鑰加密 inner ClientHello，再用 outer ClientHello 與 client-facing server 建立連線；外層只暴露用於路由的公共名稱。高品質回答還會指出 ECH 依賴 HTTPS/SVCB 記錄或其他設定分發、需要 CDN 和客戶端支援，且不能隱藏 IP、流量大小、時間和連線目的地等側通道。
回答前需要釐清的問題
觀察者與隱私目標
確認要防護的是被動網路觀察者、企業代理還是惡意中間人，以及是否仍允許閘道根據政策網域進行稽核。不同觀察者看到的 IP、DNS、外層名稱和連線時序不同。
服務拓撲與金鑰邊界
確認 ECH 在 CDN 邊緣終止還是由自建入口終止，來源站是否仍需獨立 TLS。ECH 私鑰的輪替、分發和撤銷責任必須屬於明確邊界，不能把 CDN 公鑰當成來源站憑證。
相容與回退政策
確認目標瀏覽器、作業系統、DoH/DoT、HTTP/3 和企業中間盒支援情況。回退到未加密 SNI 會恢復相容性，也會恢復觀察風險，應由政策和指標共同決定。
30 秒回答框架
「ECH 讓客戶端用伺服器發布的 ECH 公鑰加密 inner ClientHello，把真實 SNI 等敏感欄位放進內層；outer ClientHello 只帶公共名稱，讓 client-facing server 完成路由。設定通常透過 HTTPS/SVCB 等機制取得，邊緣節點解密內層後繼續普通 TLS 1.3。ECH 失敗時可按政策回退或中止，不能把回退當成同等隱私。它仍不隱藏 IP、流量大小、時間和 DNS 解析等中繼資料，所以要把 ECH 與 DNS、CDN、監控和金鑰輪替一起評估。」
分步驟深入解答
第一步：發布 ECH 設定
伺服器發布包含公鑰、版本和封裝中繼資料的 ECHConfig。客戶端透過受信任的 DNS HTTPS/SVCB 記錄或瀏覽器設定取得它，並校驗記錄來源。設定需要版本化和過期策略，舊設定不能無限期留在快取中。
第二步：建構外層和內層交握
客戶端把真實 SNI、ALPN 和其他敏感擴充放進 inner ClientHello，用 ECH 公鑰加密；outer ClientHello 只攜帶可公開的名稱和加密載荷。outer 名稱通常指向能解密 ECH 的 client-facing server，而不是直接暴露最終服務網域。
第三步：邊緣節點處理
邊緣收到 outer ClientHello 後，使用 ECH 私鑰嘗試解密 inner。成功時依內層參數選擇憑證和路由；失敗時按 TLS 規範傳送 retry 設定或終止連線。邊緣到來源站的 TLS 仍是獨立安全邊界，ECH 不會取代來源站認證。
第四步：處理回退與攻擊面
客戶端可能因設定過期、版本不相容、DNS 被竄改或中間盒阻斷而無法使用 ECH。伺服器可發布 retry 設定，客戶端重新取得後再試；若允許明文 SNI 回退，應限制場景並記錄原因。不能把任意 retry 設定直接信任為成功，防止降級和錯誤路由。
第五步：說明隱藏與未隱藏的資訊
ECH 主要隱藏 ClientHello 內的網站名稱和相關擴充。觀察者仍可能看到 DNS 查詢、外層名稱、目標 IP、交握時間、連線次數、封包長度和後續流量模式。若 DNS、CDN 和應用部署洩露唯一外層名稱，匿名集合也會變小。
第六步：金鑰與維運治理
為 ECH 私鑰設定輪替、雙人審批、回滾和緊急撤銷流程。監控設定發布時間、客戶端接受率、retry 率、解密失敗、TLS 告警、不同 CDN 節點的版本差異，並保留不含真實 SNI 的診斷識別。日誌不能為了排查而記錄 inner ClientHello 的敏感欄位。
第七步：漸進發布和驗證
先在受控網域和支援的客戶端灰度，比較 ECH 開啟、回退和中止的成功率、交握延遲、HTTP/2/3 協商與來源站錯誤。用受控的過期設定、錯誤私鑰、中間盒和多節點輪替測試失敗路徑，再驗證舊客戶端仍可按政策存取。
高品質示範回答
ECH 是 TLS 1.3 的擴充，用伺服器發布的 ECHConfig 公鑰加密 inner ClientHello。真實 SNI、ALPN 等欄位放在內層，outer ClientHello 只帶公共名稱和加密載荷；支援 ECH 的 CDN 邊緣用私鑰解密內層，再按普通 TLS 選擇憑證和路由。邊緣到來源站仍需獨立 TLS，ECH 不取代來源站認證。
我會先確認威脅模型、DNS/SVCB 設定分發、CDN 私鑰邊界和回退政策。設定過期、版本不相容或中間盒阻斷時，可以使用受信任的 retry 設定重試；只有明確允許時才回退到明文 SNI，並把原因計入指標。ECH 隱藏的是交握欄位，不是 IP、DNS、流量大小和時序。上線觀察接受率、retry、解密失敗、交握延遲和來源站錯誤，輪替金鑰時用版本化設定和可回滾流程。
常見錯誤
- 錯誤表現： 認為啟用 ECH 就等於所有造訪都匿名。→ 失敗原因： IP、DNS、連線時序和流量大小仍可能暴露關聯。→ 修正方法： 明確匿名集合和剩餘側通道，協同評估 DNS 與 CDN。
- 錯誤表現： 把 ECH 私鑰和來源站憑證當成同一把金鑰。→ 失敗原因： 邊緣解密與來源站認證是兩個安全邊界。→ 修正方法： 分離金鑰生命週期、權限和輪替流程。
- 錯誤表現： ECH 失敗後無條件回退。→ 失敗原因： 攻擊者可以製造失敗誘導降級，隱私政策失效。→ 修正方法： 對 retry、終止和回退分別設定政策與告警。
- 錯誤表現： 為了排障記錄完整 inner ClientHello。→ 失敗原因： 日誌重新暴露了本想隱藏的網站資訊。→ 修正方法： 記錄設定版本、節點和錯誤類別，不記錄敏感欄位。
追問及應對
追問一：ECH 與 ESNI 有什麼關係？
ESNI 主要只保護 SNI；ECH 把更完整的 ClientHello 放進加密的 inner 結構，並定義 outer/inner 協作和設定分發。面試中應以目前 ECH 標準和部署文件為準，不能把舊 ESNI 術語當作完整實作。
追問二：中間盒看不到真實網域後，企業如何做合規稽核？
先確認企業是否控制終端和出口閘道。受管裝置可以在終端或受信任代理保留政策需要的稽核訊號；公共網路不能因為看不到 SNI 就聲稱 ECH 破壞了 TLS。隱私目標和組織可見性要透過明確政策邊界協調。
追問三：為什麼 outer 名稱會影響隱私？
如果一個 outer 名稱只服務一個真實網站，觀察者仍可透過 IP、DNS 和名稱把連線縮小到該網站。共享入口和足夠大的匿名集合能改善隱私，但會增加路由、憑證和維運複雜度。
追問四：如何判斷是 ECH 失敗還是普通 TLS 失敗？
結合客戶端是否帶 ECH、設定版本、邊緣 retry、解密失敗計數、TLS alert、節點和時間視窗對照。對同一客戶端重複測試 ECH 開啟、關閉和舊設定，避免把憑證、ALPN 或來源站健康問題誤歸因於 ECH。