openssl为什么从1.1跳跃到3.0，为什么没有2.0版本？

news2024/11/24 2:43:49

在这里插入图片描述

OpenSSL在版本号上从1.1跳跃到3.0是因为在其发展过程中发生了一些特定的情况和变化，导致开发团队做出了这样的决定。以下是一些可能的原因：

历史背景：OpenSSL的版本号体系并不是连续递增的，而是根据项目的发展和变化进行调整。在过去的几个版本中，包括1.0.x系列，OpenSSL遇到了一些重大的安全漏洞和问题，这导致了对代码库的重大改进和修复。由于这些变化的复杂性和重要性，开发团队决定跳跃到3.0版本来突显这种巨大的变化。
主要版本更新：通常，当软件的主要版本发生重大变化时，会选择跳跃版本号，以突出这些变化的重要性。OpenSSL 3.0引入了许多重大的改进和新功能，包括对TLS 1.3的完整支持以及一些性能优化和安全增强。这些变化被认为足够显著，以跳跃到下一个主要版本号。
标准化：OpenSSL 3.0的版本号选择可能也与与TLS 1.3标准的对齐有关。TLS 1.3是一个新的协议版本，它引入了一些重大的变化和改进。通过将OpenSSL的版本号跳跃到3.0，可以与TLS 1.3的版本号对应，从而更好地反映出它们之间的关联。

需要注意的是，版本号的选择是由开发团队根据具体情况决定的，可能存在其他的原因和考虑。重要的是关注具体版本中的改进和功能，并根据自己的需求选择适合的版本。

openssl 3.0 相对于 OpenSSL 1.1.1 的主要变化

主要版本

OpenSSL 3.0 是一个主要版本，因此当前使用旧版本 OpenSSL 的任何应用程序至少需要重新编译才能使用新版本。我们的目的是，如果大多数应用程序以前使用 OpenSSL 1.1.1，那么它们将在 OpenSSL 3.0 上保持不变。但是，这并不能保证，在某些情况下可能需要进行一些更改。如果应用程序需要利用 OpenSSL 3.0 中提供的某些新功能（例如 FIPS 模块的可用性），也可能需要进行更改。

许可证变更

在以前的版本中，OpenSSL 是根据OpenSSL 和 SSLeay 双许可证（两个许可证均适用）获得许可的。从 OpenSSL 3.0 开始，它被Apache License v2取代。

提供商和 FIPS 支持

OpenSSL 1.1.1 的主要变化之一是引入了 Provider 概念。提供者聚集在一起并提供可用的算法实现。使用 OpenSSL 3.0，可以通过编程方式或通过配置文件指定您想要为任何给定应用程序使用哪些提供程序。OpenSSL 3.0 附带 5 个不同的提供商作为标准。随着时间的推移，第三方可能会分发可插入 OpenSSL 的其他提供程序。通过提供者提供的所有算法实现都可以通过“高级”API 访问（例如那些以为前缀的函数EVP）。无法使用“低级 API”访问它们。

FIPS 提供程序是可用的标准提供程序之一。这使得 FIPS 验证的加密算法可用。FIPS 提供程序默认处于禁用状态，需要在配置时使用该enable-fips选项显式启用。如果启用，除了其他标准提供程序之外，还会构建并安装 FIPS 提供程序。无需单独的安装过程。然而，有一个专用的install_fipsmake 目标，它用于仅将 FIPS 提供程序安装到现有 OpenSSL 安装中的特殊目的。

并非所有算法在特定时刻都可用于应用程序。如果应用程序代码通过 EVP 接口使用任何摘要或密码算法，则应用程序应验证EVP_EncryptInit(3)、EVP_EncryptInit_ex(3)和EVP_DigestInit(3)函数的结果。如果请求的算法不可用，这些功能将失败。

有关旧提供程序的信息，另请参阅“旧算法” 。

另请参阅“完成 FIPS 模块的安装”和“在应用程序中使用 FIPS 模块”。

低级 API

OpenSSL 历史上提供了两套用于调用加密算法的 API：“高级”API（例如 API EVP）和“低级”API。高级 API 通常设计为适用于所有算法类型。“低级”API 针对特定算法实现。例如，EVP API 提供函数EVP_EncryptInit_ex(3)、EVP_EncryptUpdate(3)和EVP_EncryptFinal(3)来执行对称加密。这些函数可以与 AES、CHACHA、3DES 等算法一起使用。另一方面，要使用低级 API 进行 AES 加密，您必须调用 AES 特定函数，例如 AES_set_encrypt_key(3) 、 AES_encrypt ( 3 )，等等。3DES 的功能有所不同。长期以来，OpenSSL 开发团队一直非正式地不鼓励使用低级 API。然而在 OpenSSL 3.0 中，这变得更加正式。所有此类低级 API 均已被弃用。您仍然可以在应用程序中使用它们，但您可能会在编译期间开始看到弃用警告（取决于编译器对此的支持）。已弃用的 API 可能会从 OpenSSL 的未来版本中删除，因此强烈建议您更新代码以使用高级 API。

“低级函数的弃用”中有更详细的描述

遗留算法

一些通过 EVP API 提供的加密算法（例如MD2和DES）现在被视为遗留算法，强烈建议不要使用它们。这些旧版 EVP 算法在 OpenSSL 3.0 中仍然可用，但默认情况下不可用。如果您想使用它们，则必须加载旧提供程序。这可以像更改配置文件一样简单，也可以通过编程方式完成。有关算法的完整列表，请参阅OSSL_PROVIDER-legacy(7) 。使用 EVP API 访问这些算法的应用程序应该使用更现代的算法。如果这是不可能的，那么这些应用程序应该确保旧提供程序已被加载。这可以通过编程或配置来实现。请参阅加密货币(7)有关提供程序的更多信息的手册页。

引擎和“METHOD”API

支持提供程序的重构与用于支持引擎的 API 发生内部冲突，包括 ENGINE API 和任何创建或修改自定义“方法”的函数（例如 EVP_MD_meth_new(3) 、 EVP_CIPHER_meth_new(3) 、EVP_PKEY_meth_new ( 3 ) 、 RSA_meth_new ( 3)、EC_KEY_METHOD_new(3)， ETC。）。这些函数在 OpenSSL 3.0 中已被弃用，这些 API 的用户应该知道它们的使用可能会绕过提供程序的选择和配置，从而产生意想不到的后果。这对于使用 OpenSSL 3.0 FIPS 模块编写的应用程序尤其重要，如下所述。强烈鼓励外部引擎的作者和维护者使用新的 Provider API 重构其代码，将引擎转换为提供者，并避免弃用的方法。

支持旧版引擎

如果 openssl 不是在没有引擎支持或已弃用的 API 支持的情况下构建的，引擎仍然可以工作。然而，它们的适用性将受到限制。

通过引擎提供的新算法仍然有效。

引擎支持的密钥可以通过自定义OSSL_STORE实现加载。在这种情况下，通过ENGINE_load_private_key(3)创建的EVP_PKEY对象将被视为遗留对象并将继续工作。

为了确保未来的兼容性，引擎应该转向提供商。要首选基于提供商的硬件卸载，您可以指定默认属性以首选您的提供商。

版本控制方案

OpenSSL 版本控制方案已随 OpenSSL 3.0 版本而更改。新的版本控制方案具有以下格式：

主要.次要.补丁

对于 OpenSSL 1.1.1 及更低版本，不同的补丁级别由发行版本号末尾的字母表示。这将不再使用，而是由版本中的最终数字指示补丁级别。第二个（次要）数字的变化表示可能已添加新功能。具有相同主编号的 OpenSSL 版本与 API 和 ABI 兼容。如果主版本号发生变化，则无法保证 API 和 ABI 兼容性。

有关更多信息，请参阅OpenSSL_version(3)。