curl 之父发文介绍 OpenSSL 分支家族

curl 之父近日发表文章介绍 OpenSSL 分支家族，展示了它们的差异、相似之处，以及支持它们所需的一些见解。

译文如下：

---

curl 支持使用 11 种不同的 TLS 库进行编译。其中六个库是 OpenSSL 或其分支。让我向你展示它们的差异、相似之处，以及支持它们所需的一些见解。

SSLeay

这一切都始于 SSLeay。这是我发现的第一个 SSL 库，我们使用这个库在 1998 年春天为 curl 添加了第一个 HTTPS 支持。显然，SSLeay 项目早在 1995 年就已经启动了。

那是一个我们还只支持 SSL 的年代；TLS 会在之后才出现。

OpenSSL 一直拥有一个古怪、不一致且极其庞大的 API 集（其中一大部分是从 SSLeay 继承而来的），这进一步被稀疏的文档所复杂化，这些文档留给用户去依靠自己的想象力和技能去查阅源代码，以获取最后的细节解答（即使在 2025 年今天也是如此）。在 curl 中，我们经常收到关于如何使用这个库的偶尔问题报告，即使已经过了几十年。 presumably，这同样适用于所有 OpenSSL 用户。

OpenSSL 项目经常受到批评，认为他们在几年前升级到版本 3 之后，在性能方面有所疏忽。他们也一直进展缓慢或不愿采用新的 TLS 技术，例如 QUIC 和 ECH。

尽管如此，OpenSSL 已经成为一种主导的 TLS 库，尤其是在开源领域。

LibreSSL

回到Heartbleed事件时期，LibreSSL分叉出来并成为独立的项目。他们删除了他们认为不属于库中的功能，创建了自己的TLS库API。几年后，苹果在macOS上使用LibreSSL提供curl。他们有一些本地修补，使它行为与其他不同。

LibreSSL在QUIC的支持上落后，不支持SSLKEYLOGFILE、ECH，而且如今在实现新功能方面似乎比OpenSSL更慢。

curl自从创建以来就与LibreSSL完美配合。

BoringSSL

在Heartbleed事件时期由Google分叉出来。Google为Google做的，他们没有公开发布过，清理了很多原型和变量类型，并在QUIC API推动中处于领先地位。总体而言，大多数新的TLS发明都已在BoringSSL中实现和支持，比其他分叉更早。

Google在Android的其他地方也使用这个。

curl 从创建以来就与 BoringSSL 完美配合。

AmiSSL

一个为使 OpenSSL 能够在 AmigaOS 上正确编译和运行而制作的 OpenSSL 分支或变种。我对它了解不多，但在这里包含它是为了完整性。它似乎基本上是为 Amiga 系统移植的 OpenSSL。

当为 AmigaOS 编译时，curl 也能与 AmiSSL 兼容。

QuicTLS

由于 OpenSSL 延迟响应并拒绝提供 QUIC API，其他分支在 2020 年初期（我尚未看到有人解释原因）采取了行动。微软和 Akamai 分支了 OpenSSL，产生了 QuicTLS，此后它试图成为一个 轻量级 的分支，主要只是在与 BoringSSL 和 LibreSSL 支持相同风格的基础上添加 QUIC API。轻量级 的含义是它们密切跟踪上游开发，并且除了 QUIC API 之外，没有打算在其他方面偏离。

在 OpenSSL 3.5 中，他们终于提供了一个与 fork（包括 QuicTLS）提供的 QUIC API 不同的 QUIC API。我认为这促使 QuicTLS 重新考虑其未来的发展方向，但我们仍在等待确切的进展。

curl 自从创建以来就与 QuicTLS 完美配合。

AWS-LC

这是由亚马逊维护的一个 BoringSSL 分支。与 BoringSSL 不同的是，他们确实进行了实际的（频繁的）发布，因此看起来像一个项目，即使是非亚马逊用户也可以实际使用和依赖——尽管他们存在的目的是 _维护一个与 AWS 使用的软件和应用程序兼容的安全 libcrypto _。令人惊讶的是，他们维护的不仅仅是“仅仅” libcrypto。

这个分支最近显示出大量的活动，甚至在核心部分也是如此。2025 年 5 月由 HAProxy 团队进行的基准测试 表明，AWS-LC 显著优于 OpenSSL。

AWS-LC 提供的 API 与 BoringSSL 的 API 并不完全相同。

curl 与 AWS-LC 从 2023 年初开始就配合得非常好。

家族树

OpenSSL 分支家族树

OpenSSL 分支家族现状

这六个不同的分支各自有其特定的特性、API 和功能，这些在不同版本中也会发生变化。目前我们仍然支持这六个分支，因为人们似乎仍在使用它们，而且维护起来是可行的。

我们使用相同的 单个源代码文件 支持所有这些分支，并通过不断增长的 #ifdef 逻辑来实现。我们通过在 CI 中使用这些分支进行构建验证，尽管只使用了一小部分最近的版本。

随着时间的推移，这些分支似乎正在逐渐彼此分离。我认为这还不构成一个问题，但我们当然在监控这种情况，可能在某个时候需要进行一些内部重构以适应这种变化。

未来

我无法预见会发生什么。如果历史是一堂课，我们似乎更倾向于走向更多的分支，而不是更少的分支。但当然，每一位阅读这篇博客文章的读者现在都会思考，所有这些分支所耗费的重复努力以及由此带来的隐含低效性到底有多少。这不仅适用于这些库本身，也适用于像curl这样的用户。

我认为我们只能等待观察。