在curl项目中，我们长期以来一直支持一系列提供类似功能的不同第三方库。构建 curl 的人员需要从提供的替代方案中决定使用哪个后端。例如，选择使用哪个 TLS 库。
这是 curl 的一个基本且值得赞赏的设计原则。它允许不同的用户根据其用例做出不同的选择和优先级。
截至 2025 年 5 月，curl 已支持13 个不同的 TLS 库。它们在功能、占用空间、速度和许可证方面各不相同。
提高标准
我们隐式地告诉用户，您可以使用此列表中的某个库来获得良好的 curl 功能。我们支持的库已获得我们的认可，并通过了测试，没有问题。
随着我们支持大量应用，我们可以提高标准，逐步提高它们获得批准的门槛。这是为了用户的利益，也是为了确保我们支持的应用确实是高质量的选择，值得我们在未来几年继续发展。
TLS 1.3
最新的 TLS 版本称为 TLS 1.3，其对应的RFC 8443于 2018 年 8 月发布，距今已有近七年。虽然前身 1.2 版本没有已知的重大问题或安全隐患，但尚未实现并支持 TLS 1.3 的现代 TLS 库却显得落后。它已经落后了。
我们借此机会提高标准，宣布从 2025 年 6 月开始，curl 将仅支持支持 TLS 1.3（其现代版本）的 TLS 库。首个包含此更改的 curl 版本是即将发布的 8.15.0 版本，计划于 2025 年 7 月中旬发布。
这一举措已经宣布、筹划并反复沟通了一年多。这应该不会令人意外，尽管我毫不怀疑有些人会对此感到意外。
这确保了那些选择使用 curl 的用户和应用程序能够更好地适应未来发展。我们不再推荐使用落后版本。
已移除
此操作影响以下两个特定的 TLS 后端：
- BearSSL
- 安全传输
BearSSL
这个嵌入式且占用空间较小的库可能最好用 wolfSSL 或 mbedTLS 来替代。
安全传输
这是 Apple 操作系统中的一个原生库，但 Apple 自己早已弃用了它。目前没有明显的原生替代品，但我们推荐 wolfSSL 或 OpenSSL 的一个分支。Apple 自己很久以前就使用 libreSSL 构建他们的 curl 版本了。
用户可能错过的安全传输的主要功能是其他后端尚未提供的功能，即能够在 Apple 操作系统（iOS、macOS 等）上使用本机 CA 存储。我们预计此功能将很快在其他 TLS 后端实现。
网络框架
在 Apple 操作系统上，安全传输层有一个后继者：网络框架。然而，这不仅仅是一个 TLS 层，而且由于其设计决策和 API 架构，它完全不适合 curl 的用途。它无法正确地公开/使用套接字，唯一的使用方法是将连接、名称解析和部分协议管理等工作交给它，这完全不可接受，而且会导致灾难。因此，curl 不太可能再次支持 Apple 操作系统上的原生TLS 库。
curl 中剩余的 11 个 TLS 后端
按照我们添加它们的顺序。
- OpenSSL
- GnuTLS
- wolfSSL
- SChannel
- libressl – OpenSSL 的一个分支
- BoringSSL – OpenSSL 的一个分支
- mbedTLS
- AmiSSL – OpenSSL 的一个分支
- rustls
- quictls – OpenSSL 的一个分支
- AWS-LC – OpenSSL 的一个分支
已删除八个 TLS 后端
随着这两项新删除，我们多年来已删除的 TLS 库集按删除顺序如下：
- QsoSSL
- 轴突信号传输协议
- PolarSSL
- MesaLink
- 国家安全战略
- 格斯基特
- BearSSL
- 安全传输
展望未来
目前，我们没有计划取消对任何其他 TLS 后端的支持，但为了项目和用户的利益，当我们认为有必要时，我们当然会保留这样做的权利。
同样，我们也没有计划添加对任何其他 TLS 库的支持，但如果有人愿意为该项目带来这样的工作，用于 curl 尚未支持的少数几个剩余的高质量 TLS 库之一，那么我们很可能会欢迎这样的努力。
原文： https://daniel.haxx.se/blog/2025/06/11/dropping-some-tls-laggards/