CA 參照解析失敗，Istio sidecar 悄悄退回明文
Istio Release Notes · 2026-09-21
當 BackendTLSPolicy 指定的 CA 憑證參照無法解析時，Istio 的 sidecar proxy 不會擋下連線，而是直接拔除上游的 TLS transport socket，把原本應該加密的流量改用明文送出。Istio 在 1.31.1（2026-09-21 發布）修補了這個問題，對應安全公告 GHSA-qm8v-g4f9-qhjx，CVSS 評分為 6.8（中度）。這是一次典型的fail open設計缺陷——使用者原本設定的是強制加密，一旦解析失敗，系統卻悄悄放行明文流量。
漏洞機制
BackendTLSPolicy 是 Gateway API 用來替後端服務指定 TLS 驗證方式的資源，其中 caCertificateRefs 欄位指向驗證所需的 CA 來源。根據 GHSA 公告，一旦這個參照解析失敗，sidecar proxy 會把原本要建立的上游 TLS transport socket 整個拔除，連線因此退回沒有加密、也沒有 CA 驗證的明文傳輸。閘道代理的行為完全相反：同樣遇到解析失敗，gateway proxy 會直接擋下連線，也就是所謂的 fail closed，於是同一份設定在兩種資料面下的安全語意並不一致。
fail open 在這裡特別危險，因為它把一個提升安全性的設定，變成了沒有警示的降級開關。公告指出，唯一會反映狀態的訊號是 BackendTLSPolicy 上的 ResolvedRefs=False，不會有連線失敗、也不會有明顯錯誤訊息提醒維運人員。對仰賴 mTLS 或後端 TLS 驗證來滿足合規要求的叢集而言，這種靜默降級意味著加密與身分驗證可能已經名存實亡，卻沒有任何告警觸發，只要 CA ConfigMap 被誤刪、改名或讀取失敗，就足以觸發這條路徑。
受影響版本
根據 GHSA 公告，受影響版本落在 1.29.0 到 1.29.6、以及 1.30.0 到 1.30.3 這兩個分支，官方分別在 1.29.7 與 1.30.4 完成修補，本次 1.31.1 則是同一顆修補在最新分支的落地版本。影響範圍限定在使用 sidecar 資料面且部署了 BackendTLSPolicy 的叢集，僅用閘道作為資料面的部署不受影響，因為 gateway proxy 本來就是 fail closed。維運人員應檢查每一份 BackendTLSPolicy 的 caCertificateRefs 是否指向存在且穩定的 ConfigMap，確認 ResolvedRefs 狀態沒有變成 False，並排查混合部署中仍以 sidecar 方式注入的 workload。
修補與緩解
升級到 1.31.1（或對應分支的 1.29.7、1.30.4）之後，CA 參照解析失敗會恢復成阻擋連線，而不是退回明文。在升級之前，官方建議優先採用 WellKnownCACertificates: System，並確保被參照的 CA ConfigMap 存在且不會被意外修改或刪除。更保守的作法是不要只依賴 BackendTLSPolicy 這一層，另外用 STRICT mTLS 獨立強制上游加密，這樣即使解析失敗，連線也不會整個退回明文。
| 修補前（sidecar，<1.31.1） | 修補後（sidecar，1.31.1+） | |
|---|---|---|
| CA 參照解析失敗時 | 拔除 TLS transport socket，退回明文傳輸 | 阻擋連線，不建立未加密的上游連線 |
| 可觀測性 | 僅 ResolvedRefs=False，無連線層級警訊 | 連線失敗，行為與 gateway 代理一致 |