End Of Live OpenSSL 1.1 vs Slow OpenSSL 3.0

End Of Live OpenSSL 1.1 vs Slow OpenSSL 3.0

【英文原文】
你可能已经注意到,OpenSSL 1.1.1 系列将于下周一(2024 年 5 月 27 日)达到寿命终止(EOL)……
最明智的选择是尽快切换到 3.0 或 3.1 版本。

当然,我们的 mORMot 2 OpenSSL 单元在 1.1 和 3.x 分支上运行,并在运行时自适应每个分支之间存在的各种 API 不兼容性。
但我们也发现,切换到 OpenSSL 3.0 可能会导致性能大幅下降……那么你需要使用哪个版本呢?
OpenSSL 1.1 将寿命终止

众所周知,广泛使用的 OpenSSL 1.1.1 系列将于 2023 年 9 月 11 日(下周一)达到寿命终止(EOL)。:(
OpenSSL 1.1.1 的用户应该考虑他们的选择,并计划他们可能需要采取的任何行动。

请注意,Indy 用户仍然停留在 OpenSSL 1.0 分支,甚至 1.1 还没有正式支持。一些替代的 IO 处理程序能够在一定程度上使用最新版本。
Indy 用户应该转而使用支持更好的库,比如我们的小 mORMot。

还要注意的是,1.1 和 3.x 之间存在一些 API 不兼容性。函数被重命名,甚至被删除;出现了新的上下文构造函数;一些参数类型甚至发生了变化!
我们的单元试图在运行时解决所有这些问题,并针对 OpenSSL 库的多个版本进行了测试,以确保您不必担心这些低级问题。

OpenSSL 3.x 的好处

随着 OpenSSL 3.0 的发布,开发人员对库的内部进行了大规模的重构。
公平地说,OpenSSL 的 1.x 源代码有点混乱,难以维护。最大的 IT 公司甚至创建了自己的分支或切换到其他库。最著名的是 BoringSSL,由 Google 维护,并在 Chrome 和 Android 等中使用。
因此,进行重构是时候了,特别是对于像 OpenSSL 这样对许多项目至关重要的库。

在新的 3.x 分支中,许多低级 API 函数已被弃用。
实际上,您不再直接访问库的内部结构,现在应该始终使用高级 API 来访问上下文属性或执行处理方法。例如,低级的 AES_encrypt 函数不再可用:从现在开始,您需要使用高级的 EVP_Encrypt* API。
官方的迁移指南页面显然非常庞大,如果您想为未来几年使用 OpenSSL 做好准备,值得一读。

OpenSSL 3.0 性能回归

3.0 分支的新代码可能看起来更漂亮,更易于维护,但它也有缺点。新的并不总是更好的。
这个新版本的大多数用户在从 1.x 切换到 3.0 时观察到了巨大的性能回归。它影响了许多项目,来自各种语言,甚至是在性能方面本来就不突出的脚本语言。据报道,时间回归从 3 倍到 10 倍不等。在我们这边,X509 证书操作确实比以前慢得多——最糟糕的是关于 X509 存储。

一些减速是预期的并记录在案(例如 RSA 密钥生成,现在使用 64 轮)。但回归要严重得多。
罪魁祸首似乎不是核心加密代码,如 AES 缓冲区编码(asm 声称在 3.x 分支上进一步优化),而是 OpenSSL 上下文结构本身。它们是为了未来的可维护性而重写的,但没有关注它们的实际性能。

OpenSSL 3.1 的数字

3.1 分支声称已经解决了这些问题中的大部分。

可以肯定的是,我们使用多个版本的 OpenSSL 运行 mORMot 加密回归测试。实际上,OpenSSL 3.1 比 OpenSSL 3.0 快得多,但仍落后于 OpenSSL 1.1。

以下是在 Win32 上执行整个 TTestCoreCrypto 方法时观察到的数字:

OpenSSL 1.1 = 15 秒
OpenSSL 3.0 = 33 秒
OpenSSL 3.1 = 18 秒

有几个方面需要强调:

这些测试还运行了 mORMot 引擎加密,因此您不仅仅是在测试 OpenSSL:在上述数字中,“纯 mORMot”测试大约需要 4.5 秒;

任何严肃的项目都应该考虑在 Win64 上编译,并在 x86_64 Linux 上运行服务器 - 在这个平台上,回归确实存在,但只是稍微好一点;

与 TTestCoreCrypto.Catalog(即证书处理)相比,TTestCoreCrypto.Benchmark(即原始缓冲区加密)受到的减速影响较小;

我们的测试是单线程的,并且在重度线程化的进程中报告了更严重的减速(高达 x10)。

在 mORMot OpenSSL 包装器中,我们尝试尽可能多地缓存上下文。例如,我们不会为每个调用按名称查找 OpenSSL 算法,而是在运行时缓存它以避免任何减速。

但对于 OpenSSL 3.0 来说,这似乎还不够,这可能会影响您的应用程序性能。

支持还是不支持

因此,OpenSSL 3.1 似乎是前进的方向。

在 Linux(或其他 POSIX 系统)上,您可能会使用系统附带的库。

因此,您不必担心使用哪个版本。而且,可悲的是,您的发行版很可能提供 OpenSSL 3.0 而不是 OpenSSL 3.1。

在 Windows(或 Mac)上,您可以(应该?)使用您“自己的”dll/so 文件,因此您必须考虑库的支持级别。

OpenSSL 3.0 是一个长期支持(LTS)版本,将维护到 2026 年 9 月 7 日。

OpenSSL 3.1 将仅支持到 2025 年 3 月 14 日。

这些支持结束日期可能看起来违反直觉,但这是开源项目中的常见方式,最著名的可能是 Ubuntu LTS 版本。

有关 OpenSSL 支持生命周期的更多信息,请查看官方 OpenSSL 下载页面。

因此,对于大多数项目,特别是在 Windows 上,您可能会发布带有自己可执行文件的 OpenSSL dll,切换到 OpenSSL 3.1 可能是前进的方向。

如果您需要为您的产品收集一些安全认证,您可以考虑使用 OpenSSL 3.0 LTS 版本,这可能有助于您的认证在更长时间内保持有效。

一如既往,欢迎在我们的论坛上提供任何反馈!

热门相关:饲养的已婚妇女   我怎么无敌了   新版:破茧   隐秘的来客   妈妈的朋友们2