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 版本，这可能有助于您的认证在更长时间内保持有效。

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