OpenSSL 4.0 与 3.6：TLS 库的演进、QUIC 支持与迁移代价
通用 TLS 和加密库。下载 ======== 用于生产用途 可以从 openssl-library.org/source/ 下载官方版本的源代码 tarball。
秒懂
- 它是什么？
- OpenSSL 是 TLS、DTLS 与 QUIC 协议的基础实现，同时提供通用密码学库和命令行工具。本文基于 4.0.2、3.6.4 等近期版本，分析其架构、构建方式、许可证约束，以及哪些场景下它并非合适选择。
- 适合谁用？
- OpenSSL 适合需要完整 TLS 1.3、DTLS 1.2 或 QUIC v1 支持的生产系统，尤其是必须通过 FIPS 验证的政府或金融项目。它不适合只想做简单 HMAC 或 AES 的小型嵌入式项目，因为 libcrypto 的体积和构建复杂度可能超出需求。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 C（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个库，三件工具：它解决什么问题
OpenSSL 解决的是网络通信中的加密与身份验证问题。它提供 libssl，实现 TLS 1.3、DTLS 1.2 和 QUIC v1 协议；提供 libcrypto，作为通用的密码学原语库，可独立于 TLS 使用；还提供 openssl 命令行工具，用于生成密钥参数、创建 X.509 证书、计算摘要、加解密，甚至测试 QUIC 客户端。这个项目面向的是需要构建安全通信层的开发者、系统管理员，以及需要合规性（如 FIPS）的机构。它不是一个小巧的库，而是一个覆盖协议栈、密码算法和证书管理的完整工具集。
从 SSLeay 到 4.0：架构的延续与变化
OpenSSL 源自 Eric A. Young 和 Tim J. Hudson 编写的 SSLeay 库。今天的代码库仍然保留了这个血统，但架构已经演进。README 中明确区分了三个组件：libssl 负责协议状态机，libcrypto 提供底层算法，命令行工具则是对两者的封装。这种分层意味着你可以只链接 libcrypto 而不引入 TLS 代码。文档还提到了 Provider 架构，相关说明在 README-PROVIDERS.md 中，它允许将算法实现作为可加载模块。对于 4.0 版本，QUIC 支持是重点之一，README 列出了专门的 QUIC 实现说明文件。这种模块化设计让 OpenSSL 能同时服务传统 TLS 应用和新兴的 HTTP/3 场景，但也增加了配置的复杂度。
获取与构建：官方只发源码，二进制靠系统
官方明确表示不提供二进制分发。生产环境应从 openssl-library.org/source/ 下载源码 tarball。对于 Linux 和 Unix 系统，README 建议链接发行商提供的预编译共享库。开发或测试时，可以克隆 GitHub 镜像，命令是 git clone https://github.com/openssl/openssl.git。构建前必须阅读 INSTALL.md，不同平台还有额外说明，例如 NOTES-UNIX.md、NOTES-WINDOWS.md、NOTES-ANDROID.md。构建过程依赖 Perl，这一点在 NOTES-PERL.md 中有说明。这种发布策略意味着，如果你需要最新特性（比如 4.0 的某些新 API），你必须自己编译，而不能直接使用系统自带的旧版本。
FIPS 模块：合规性如何体现
README 提到 OpenSSL 包含一个经过 FIPS 标准验证的密码学模块。具体使用方式在 README-FIPS.md 中说明。这意味着对于需要满足美国政府合规要求的项目，OpenSSL 提供了一条相对直接的路径，而不必自己实现算法并通过认证。但要注意，FIPS 模块是独立于主库的，启用它需要特定的配置和构建选项。文档没有详细列出这些步骤，所以实际部署时你需要查阅相关手册。这个特性是 OpenSSL 区别于许多轻量级加密库的关键，但也是一把双刃剑，因为 FIPS 模式可能限制某些算法的可用性，或者要求额外的密钥管理流程。
升级到 3.x 或 4.0：迁移成本在哪里
README 指向 ossl-guide-migration(7ossl) 手册页，专门说明从旧版本升级到 3.x 的注意事项。这暗示了迁移并非无痛。OpenSSL 3.x 引入了 Provider 架构，改变了算法加载的方式，许多旧的 API 被标记为废弃。如果你维护一个长期未更新的项目，升级到 3.6 或 4.0 可能需要修改代码，例如替换直接调用 EVP 接口的方式。另外，命令行工具的某些输出格式也可能变化。文档没有给出具体迁移清单，但明确要求用户阅读该手册，这意味着迁移风险是官方承认的。对于只使用命令行工具的用户，升级可能相对简单，但开发库的用户必须进行回归测试。
许可证与法律边界：Apache-2.0 的含义
OpenSSL 采用 Apache License 2.0，允许商业和非商业使用，只要满足其条件。这与早期 OpenSSL 的双许可证（OpenSSL License 和 SSLeay License）不同，后者曾给一些项目带来兼容性困扰。Apache-2.0 对专利授权有明确条款，这对企业用户更友好。但 README 也提醒，许多国家限制密码学软件的使用或出口。如果你处于这样的司法管辖区，应在开发或分发前寻求法律建议。这个法律警告不是空话，因为密码学库的国际流通确实受到管制。作为评估者，你需要确认你的部署地区是否允许使用强加密算法。
何时不该用 OpenSSL：替代方案与边界
OpenSSL 是通用工具，但并非所有场景都适合。对于内存受限的嵌入式设备，libcrypto 的体积可能过大，这时可以考虑更轻量的库，比如 mbedTLS，它专注于 TLS 且占用更小。另一个替代是 BearSSL，它强调代码简洁性和可审计性，但功能范围较窄。与这些库相比，OpenSSL 的优势在于完整的协议支持（如 QUIC）和 FIPS 验证，但代价是更高的复杂性和更大的攻击面。如果你只需要 AES 加密，而不需要 TLS 或证书管理，那么直接使用内核提供的 crypto API 或一个单一算法库可能更简单。文档中没有提及这些替代品，但这是从 OpenSSL 的组件划分中得出的判断。
编辑结论
OpenSSL 适合需要完整 TLS 1.3、DTLS 1.2 或 QUIC v1 支持的生产系统，尤其是必须通过 FIPS 验证的政府或金融项目。它不适合只想做简单 HMAC 或 AES 的小型嵌入式项目，因为 libcrypto 的体积和构建复杂度可能超出需求。若你正从 3.x 迁移，先阅读 ossl-guide-migration(7ossl) 手册页，检查你的代码是否依赖已废弃的 API。对于 QUIC 应用，需确认你使用的分支是否包含 README-QUIC.md 所述的稳定接口，因为 4.0 与 3.6 的 QUIC 实现细节可能有差异。最后，验证你的系统包管理器提供的 OpenSSL 版本是否与你的目标版本一致，避免链接到多个版本导致符号冲突。
社区笔记