OpenSSL 3.0已经发布了，随着它的发布，这个几乎到处都用来实现SSL/TLS的流行库有了一些明显的变化。截至目前，OpenSSL 1.1.1分支仍在积极开发中，因此虽然值得评估提升你的应用程序，但到目前为止还没有什么紧迫性。事实上，OpenSSL 1.1.1被指定为一个LTS版本，并将在2023年9月之前收到安全修复。OpenSSL 3.0带来了几个显著的变化，包括一个新的版本系统和一个不同的开源许可结构。OpenSSL 3.0是一个主要的版本，并不向后兼容。此外，OpenSSL 3.0还包括一个新的模块，该模块只执行符合FIPS标准的加密技术。

对版本的改变

OpenSSL以前的版本依赖于标志性的 "字母 "系统，例如OpenSSL 1.1.1k。今后，OpenSSL将更紧密地与语义上的版本管理保持一致，利用一个版本字符串，如：3.0.1

其中3表示主要版本，0表示次要里程碑，1表示补丁级别。这是很有用的，因为它直接在版本字符串中封装了更多信息。如果补丁级别发生变化，很可能有一个值得应用的安全修复，而如果次要版本发生变化，你将会与你的应用程序供应商进行对话

许可证变化
OpenSSL在历史上一直是按照自己的大杂烩式的许可条款进行许可。最后，OpenSSL项目已经在一个标准的开源许可证下发布，特别是Apache许可证v2.对软件的修改要明确列举出来。从安全标准来看，Apache许可证是OpenSSL的一个很好的选择，因为它要求对源代码的任何修改都要明确列举出来。

旧API的废弃

在这个版本中，有大量丢弃的API变化，有些是预期的，有些是意外的。历史上，OpenSSL的API被分为两类。"高层 "API在用户和他们选择的算法之间提供了一个抽象层（尽管算法的选择可能是这些高层API的一个参数），而 "低层 "API则是特定算法。高层API已经达到了一定的成熟度，使用低层API不再为开发者提供切实的好处，因此未来的OpenSSL版本将可能完全删除这些低层API。目前，你可以使用它们，但编译时将会出现大量的警告。

对内核TLS的支持

在Linux内核的4.13版本中，发布了对用户空间进程的支持，将某些加密操作卸载到操作系统中，这导致了一些令人印象深刻的性能改进。支持内核TLS的意义在于，自2017年4.13版本发布以来，推进内核TLS往往意味着分叉OpenSSL来实现。在github上有许多针对OpenSSL 1.1.1的分叉，然而这种碎片化会导致安全性严重下降。为了尽量减少在操作系统代码库中的占用，同时最大限度地提高性能，只有被称为 "TLS记录层 "的实际对称部分是由内核直接处理的--即使在使用内核TLS时，TLS握手也是由用户区应用程序（在这种情况下是OpenSSL）促成的。这使得系统调用sendfile() man7.org/linux/man-pages/man2/sendfile.2.html可以避免不必要的复制到用户空间，而最终在加密后再复制到内核空间。此外，利用内核TLS，可以利用能够在硬件中进行实时加密的网卡。

FIPS模块

联邦信息处理标准（FIPS）是由美国政府执行的一套要求，管理公共部门的密码使用。对于那些没有义务遵守该标准的人来说，利用FIPS实际上可能弊大于利--符合FIPS的算法和工具已经通过了一套严格的第三方验证，但当涉及到能够利用该领域的一些最新和最伟大的研究时，这种繁重而昂贵的验证任务带来了巨大的延迟，即使该研究是健全和合理的。(例如，椭圆曲线加密法被所有的人认为是合理安全的，但FIPS的支持出了名的滞后）。

我应该做什么？

如果你是一个管理员，请抓紧时间。应用程序提供商在2023年之前必须使他们的代码库与OpenSSL 3.0兼容。如果你是一个开发者，谨慎的做法是确定支持OpenSSL 3.0所需的努力程度。除了根据新的libcrypto重新编译他们的应用程序外，绝大多数依赖OpenSSL的开发者不需要做任何改变。仍在使用低级别的API的开发者应该考虑现在是否是改变他们的代码以利用高级别的API的适当时机，以便面向未来并消除那些讨厌的编译器警告。最后，检查一下发布页面，看看一些比较小众的兼容性问题是否适用于你 - github.com/openssl/openssl/issues?page=3&q=is%3Aissue+is%3Aopen

结论

OpenSSL 3.0是OpenSSL项目的一个巨大的里程碑，一些代码库的简化早就应该完成了。在许多方面，这些变化似乎是为了摆脱OpenSSL项目一直以来的一些怪癖，包括其定制的许可和奇特的版本命名法。在OpenSSL 3.0达到OpenSSL 1.1.1那样的普遍性之前，还需要相当长的时间，而在对该版本的支持最终落地之前，还需要更长的时间。