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？
不应。根据平台和后端选择并记录合理策略。本次修复要求验证优先级，不是要求全面弃用原生证书库。
合规说明
只在你控制或获准使用的代理端点、测试根、机器和目标服务上测试。不要把实验根证书安装到共享生产证书库，不要关闭验证、拦截第三方流量，也不要暴露代理凭据与私钥材料。
