2024 年 5 月，我们最终决定，也许是时候让curl 放弃对旧版 TLS 库的支持了。由于不支持许多用户的现代 TLS 版本 (1.3)，这些库可能不适合将来构建。我们给了世界 12 个月的时间来适应或反对。时间已经过去一大半了。
这意味着，在 2025 年 5 月之后，我们打算放弃对 Secure Transport 和 BearSSL 的支持，除非出现重大变化让我们重新考虑。
这篇博文试图让每个人都更加了解，并确保那些需要的人做好适当的准备。
安全传输
Secure Transport 是一个相当可怕的名字，但它仍然是 Apple 编写的 TLS 库的名称，作为 macOS 和所有不同风格的 iOS 的组件提供。自 2012 年以来，curl 一直支持它，但几年前，它被 Apple 自己视为已弃用和“遗留”。安全传输仅支持 TLS 最高但不高于 1.2。
曾几何时，Apple 在 macOS 上发布了针对 Secure Transport 构建的curl，但几年前他们转向了 LibreSSL。
我听说人们仍然喜欢在 iOS 上使用 libcurl/Secure Transport 的两个主要原因：
- 它使他们不必使用和捆绑单独的第三方库，这也增加了占用空间。
- 它使他们能够轻松方便地使用 iOS 证书存储，而不必管理单独的证书存储。
网络架构
继续他们奇怪的命名轨迹，苹果建议全世界使用而不是安全传输的东西称为网络框架。
由于全新的范式和（至少对我来说）设计 API 的有趣方式，为使用 TLS 网络框架的curl 编写后端远非直截了当。我们甚至没有看到有人尝试过。 Apple 自己似乎完全可以不使用自己的 TLS 来构建curl。
我不确定尝试在curl中使用网络框架是否明智。
选项
如果没有安全传输，也看不到网络框架支持，macOS 和 iOS 版本上的 libcurl 用户需要决定下一步该做什么。
我可以想象有几种不同的选择可供选择。
- 坚持使用旧的 libcurl。起初这是一个简单方便的选择，但很快就会发现这是一条狭窄的道路，并且未来可能存在潜在的安全隐患。
- 维护自定义补丁。 TLS 后端相当独立，因此这可能不是一项不可能的任务，但仍然需要大量的工作，并且需要一定的技能。
- 关闭 libcurl 。假设您找到了一个提供类似功能、稳定性、可移植性、速度并且支持本机证书存储的替代方案。可能意味着相当多的工作。
- 将 libcurl 与另一个 TLS 库结合使用。这本身就是两个子类别。 A) 最简单的途径是接受您需要维护一个单独的 CA 存储，然后您可以立即执行此操作，并且您可以使用支持最新标准且得到良好支持的 TLS 库。 B) 使用支持使用本机 iOS 证书存储的 TLS 库。我相信现在 WolfSSL 可能是唯一一个开箱即用的解决方案，但也可以选择付费给某人或编写代码以将此类功能添加到另一个curl TLS 后端。
- 其他一些方法
去除后
从curl中删除了对两个库的支持后，仍然支持十个不同的TLS库。每个人都应该有足够的选择——没有什么可以阻止我们为未来的新人提供支持。
抗议被听取
curl弃用过程的一部分是，我们倾听人们在代码被删除的实际未来日期之前可能提出的反对意见。如果有适当的动机，弃用决定可以被取消或至少推迟。
原文： https://daniel.haxx.se/blog/2025/01/14/secure-transport-support-in-curl-is-on-its-way-out/