高吞吐量代理應用程式會重用連線，以減少 TCP 與 TLS 交握成本。但當不同請求使用不同 CA 設定、憑證釘選規則、代理路線或租戶政策時，進入同一連線集區可能造成信任邊界混淆。
安全設計不是完全停用重用，而是把信任設定納入連線身分，以負向測試證明隔離，並在邊界變更時關閉不再適用的連線。
先定義完整的信任設定
信任設定是判斷 TLS 對端是否可接受的全部規則。為每套設定配置不可變的內部 ID，至少包含：
- 是否啟用作業系統原生 CA 儲存區；
- 自訂 CA 套件或信任庫版本；
- 憑證或公開金鑰釘選集合；
- 主機名稱驗證政策；
- TLS 最低與最高版本；
- 雙向 TLS 使用的客戶端憑證身分；
- 代理通訊協定、主機、連接埠與代理 TLS 設定；
- 會改變以上任一項目的租戶、地區或工作負載政策。
不要用易變的顯示名稱作為身分。應先正規化設定，再計算不含秘密的 trust_profile_id。
代理情境要分別識別兩段鏈路
經代理傳送 HTTPS 請求時，可能有兩個受保護鏈路。TLS 代理有自己的憑證和信任判斷，目的地還有另一套。CONNECT 通道也可能在代理連線內保留獨立的端對端 TLS 工作階段。
因此要分別記錄：
- 代理鏈路：代理通訊協定、主機、連接埠、代理 CA 政策和代理客戶端憑證。
- 目的地鏈路：目的地主機、目的地 CA 政策、釘選集合和目的地客戶端憑證。
即使代理路線不變，目的地信任設定變更後也不能預設重用原連線。同樣，代理信任變更不能繼承既有代理 TLS 工作階段。
建立完整的連線集區鍵
連線集區鍵必須區分會改變路由、對端身分或信任判斷的所有設定。可採用以下概念模型：
傳輸協定 + 代理端點 + 代理信任設定 + 目的地端點 + 目的地信任設定 + 客戶端身分 + 隱私分區
不同程式庫的欄位會不同，但不變原則相同：有效信任判斷不同的兩個請求，絕不能競爭同一個活動連線。
若連線集區由客戶端程式庫內部管理，應檢查其重用規則並測試實際行為。重用 handle 上的設定 setter 不一定會使所有相關連線失效。
用雙設定負向測試證明隔離
正向測試只能說明核准憑證可用；負向測試才能證明信任不會串用。
準備兩個受控 TLS 目的地或代理監聽器：
- 設定 A 信任測試 CA A，並拒絕 CA B；
- 設定 B 信任測試 CA B，並拒絕 CA A；
- 每個監聽器使用獨立的伺服器端路線標記。
依正式環境的客戶端生命週期執行：
- 使用設定 A 請求目的地 A，應成功。
- 使用設定 B 請求目的地 B，應成功。
- 使用設定 A 請求目的地 B，應發生憑證失敗。
- 使用設定 B 請求目的地 A，應發生憑證失敗。
- 在允許連線重用時執行 A → B → A。
- 停用重用後重複，作為控制組。
- 在正式環境 multi handle、工作程序或共享快取拓撲中重複。
若故意錯誤的設定只在先前成功請求後被接受，應立即阻止推出。
測試長生命週期客戶端的設定變更
許多問題只會在客戶端已連線後修改設定時出現。每次只改變一個維度：
- 原生 CA 儲存區開 → 關 → 開；
- CA 套件版本 A → B → A；
- 釘選集合 A → B → A；
- 代理連接埠 A → B → A；
- 同一工作程序中的租戶 A → 租戶 B；
- 若政策允許，直接連線 → 代理 → 直接連線。
預期結果只能是正確隔離的重用連線，或一次新交握。舊政策驗證過的連線不能作為新政策的信任證據。
記錄證據但不洩漏秘密
每次傳輸建議記錄：
- 請求 ID 與追蹤 ID；
- 客戶端及 TLS 程式庫版本；
- 正規化代理端點標籤；
- 目的地端點標籤；
proxy_trust_profile_id與origin_trust_profile_id；- 連線 ID 及新建或重用狀態；
- 協商的 TLS 版本和政策允許的憑證指紋；
- 成功、憑證拒絕、代理驗證、逾時或政策攔截等結果分類；
- 重試次數及最終路線。
禁止記錄私密金鑰、代理密碼、權杖、原始 Cookie、完整代理 URL 或完整客戶端憑證。設定 ID 應由設定標籤計算，不能由秘密計算。
回退與重試必須故障關閉
信任失敗不是一般的暫時性網路錯誤。自動改用較寬鬆的信任設定，可能把安全拒絕變成非預期存取。
- 憑證錯誤後不得關閉驗證；
- 不得從釘選設定自動退到未釘選設定；
- 除非政策明確允許，否則不能繞過代理；
- 重試必須有上限，並保留原信任設定；
- 政策失敗應與容量失敗分開告警。
可使用代理繞過稽核檢查意外直接連線，並透過代理容錯移轉復原演練驗證核准的備援路線。
安全推出步驟
- 盤點信任設定及其負責人。
- 在設定與日誌中加入不可變設定 ID。
- 擴充連線集區鍵，或按設定隔離連線集區。
- 在 CI 中部署負向測試矩陣。
- 只用少量獲授權流量進行金絲雀推出。
- 觀察憑證失敗、重用率、交握率、延遲和直接連線嘗試。
- 信任設定變更時排空舊連線集區。
- 回復程式碼時不得恢復過期信任庫。
同時搭配代理憑證輪換，確保憑證與信任資料可獨立變更。
驗收清單
- 每個請求都能解析出明確的代理與目的地信任設定 ID。
- 不同信任設定無法共享活動連線。
- 錯誤 CA 與錯誤釘選集合測試穩定失敗。
- 長生命週期 handle 的設定變更會隔離連線或重新交握。
- 未明確核准時不存在直接連線回退。
- 重試保留原信任政策且有上限。
- 日誌不含秘密或完整代理 URL。
- 信任庫變更後舊連線集區已排空。
- 監控能區分憑證、驗證、路由和容量錯誤。
常見問題
一個程序能安全服務多套信任設定嗎？
可以，前提是連線集區、快取、客戶端身分與日誌都按完整設定分區。高敏感邊界使用獨立程序通常更簡單。
代理 CA 儲存區等於目的地 CA 儲存區嗎？
不一定。TLS 代理和目的地是兩個獨立對端，應分別建立模型並測試信任規則。
憑證錯誤應該重試嗎？
通常不應按一般暫時性錯誤重試。只有在保持相同信任要求、目的明確且次數受限的政策下才可重試。
CA 套件更新後要做什麼？
增加信任設定版本，禁止重用舊設定建立的連線，排空舊連線集區，並重新執行正向與負向測試。
來源背景與合規
本文參考 curl 專案於 2026 年 9 月 2 日發布的「native CA store conn reuse」安全公告。該公告說明 Windows 與 macOS 上受影響的連線重用行為，並建議升級至 curl 8.22.0。外部來源地址只保留在內部營運記錄中。
代理及資料收集系統只能用於獲授權範圍。請遵守隱私義務、合約、速率限制、存取控制及地區法律。信任隔離是安全控制，不是繞過平台保護的方法。
