curl 8.22 修正 HTTPS 代理 CA Blob 與 Native CA 選擇
curl 專案 2026 年 9 月 2 日發布的 8.22.0 變更記錄列出一項代理 TLS 修正：libcurl 現在會在啟用 Native CA 時正確採用 CURLOPT_PROXY_CAINFO_BLOB。此變更適用於連線 HTTPS 代理、從記憶體提供代理 CA 資料，同時啟用系統原生憑證庫的應用程式。
這不表示所有 curl 代理部署都存在安全問題。它是特定設定的優先順序修正。正確做法是核對真實執行路徑，在適用時升級，並以受控憑證矩陣證明實際採用的信任政策。
公開來源說明：curl 專案《curl 8.22.0 changelog》，2026 年 9 月 2 日；curl 專案《TLS Certificate Verification》文件，複核於 2026 年 9 月 10 日。
修正內容
libcurl 將 HTTPS 代理 TLS 驗證與通道後目標伺服器的 TLS 驗證分開。應用程式可透過 CURLOPT_PROXY_CAINFO_BLOB 從記憶體提供代理 CA PEM 資料，也可在後端支援時透過代理 TLS 選項要求使用系統 Native CA。
8.22.0 變更記錄說明代理 CA blob 現在會優先得到正確處理。因此，不能用另一 curl 版本、TLS 後端或作業系統的經驗推斷目前行為，必須對預期代理信任來源做迴歸驗證。
兩條 TLS 路徑不可混淆：
| TLS 路徑 | 驗證對象 | 對應政策 |
|---|---|---|
| 用戶端到 HTTPS 代理 | 代理主機名稱與代理憑證鏈 | 代理專用 CA 與驗證選項 |
| 代理通道到 HTTPS 目標 | 目標主機名稱與目標憑證鏈 | 來源 CA 與驗證選項 |
成功收到目標回應，不能證明代理憑證使用了預期信任來源。
判斷是否適用
依序確認：
- 應用程式使用 libcurl，而不只是 curl 命令列；
- 代理 URL 使用 HTTPS，確實存在到代理的 TLS；
- 程式碼設定
CURLOPT_PROXY_CAINFO_BLOB； - 程式碼或建置為代理驗證啟用 Native CA；
- 目前 TLS 後端支援相關選項；
- 部署版本早於已修正版本。
按二進位檔或容器映像記錄結果。同一應用可能在不同系統封裝不同 libcurl 與後端。
建議記錄應用程式組建、libcurl 版本、TLS 後端、作業系統、代理協定、代理對等與主機名稱驗證、是否設定 CA blob、是否啟用 Native CA，以及來源 CA 來源。不得記錄私密金鑰、代理憑證、權杖、Cookie 或正式環境機密。
建立受控信任矩陣
使用自有或獲准測試的 HTTPS 代理，準備兩個非正式環境測試根憑證：
- Blob 根： 只存在於記憶體代理 CA blob；
- Native 根： 只安裝在隔離測試系統的原生憑證庫。
分別為同一個已授權代理主機名稱簽發代理憑證。保持主機名稱驗證開啟、目標憑證有效，並讓目標回傳無害標記。
至少執行 Blob 根、Native 根、完全不受信任根，以及主機名稱錯誤憑證四種情況。每次都預先寫明預期。組合政策會依 TLS 後端及文件化選項語意而異，不能根據結果倒推期望。
保存版本、後端、選項、代理主機名稱、憑證簽發者指紋、驗證結果、curl 錯誤碼、目標標記與耗時。只保存必要指紋，不保留無必要完整憑證鏈。
安全比較修正前後版本
使用完全相同的應用程式碼、憑證樣本、代理端點、目標、環境與選項順序，比較已部署組建與 curl 8.22.0 或包含修正的供應商組建。
關鍵控制項：
- 每個案例使用全新程序，避免 CA 快取跨案例；
- 不關閉對等或主機名稱驗證；
- 不替換成 HTTP 代理，因為會移除代理 TLS；
- 只改變代理信任，保持來源信任固定；
- 重試前保存首次失敗；
- 分別測試每個正式環境 TLS 後端。
代理 TLS 工作階段恢復測試可協助分別保存握手與連線重用證據。通道建立後應用內容改變時，可使用請求標頭完整性測試。
避免不安全應急方案
不要將 CURLOPT_PROXY_SSL_VERIFYPEER 設為零，也不要弱化主機名稱驗證。只有加密而沒有身分驗證，無法證明用戶端連線至預期代理。
較安全措施包括：
- 升級至 curl 8.22.0 或包含修正的供應商套件；
- 透過常規軟體維護流程套用上游修補；
- 暫時簡化為一個明確記錄的代理信任來源；
- 將信任矩陣加入發布驗收。
記憶體 CA blob 避免了檔案路徑，但仍需明確所有者、輪換、到期與稽核責任。
部署檢查清單
- 確認實際部署的 libcurl 版本與 TLS 後端。
- 確認代理協定為 HTTPS。
- 搜尋
CURLOPT_PROXY_CAINFO_BLOB與代理 Native CA 設定。 - 將代理與目標 CA 政策分開。
- 測試 blob-only、native-only、不可信根與錯誤主機名稱。
- 保持對等與主機名稱驗證開啟。
- 對每個支援系統與後端複測。
- 漸進發布並監控代理 TLS 驗證錯誤。
- 記錄信任政策及憑證輪換負責人。
- 不記錄憑證、私密金鑰、CA blob 內容或敏感流量。
常見問題
一般 HTTP 代理受影響嗎？
此信任選擇問題針對到 HTTPS 代理的 TLS。一般 HTTP 代理沒有代理憑證驗證環節，但通道內仍可能存在目標 TLS。
目標 CA 與代理 CA 相同嗎？
不是。它們驗證不同 TLS 對端，libcurl 提供代理專用選項以保持政策分離。
請求成功能證明使用了 CA blob 嗎？
不能。另一個信任來源也可能接受憑證。應使用只被單一測試來源信任的憑證證明選擇。
是否應在所有環境關閉 Native CA？
不應。依平台和後端選擇並記錄合理政策。本次修正要求驗證優先順序，不是要求全面棄用原生憑證庫。
合規說明
只在你控制或獲准使用的代理端點、測試根、機器與目標服務上測試。不要把實驗根憑證安裝到共享正式環境憑證庫，不要關閉驗證、攔截第三方流量，也不要暴露代理憑證與私密金鑰材料。
