OpenSSL项目中关于Nginx无法正确记录PQC组名问题的技术解析

在OpenSSL 3.5版本中引入了对后量子密码学(PQC)的支持，包括混合密钥交换方案和纯MLKEM组。然而，这一变化带来了一个与Nginx日志记录相关的兼容性问题。本文将深入分析这一技术问题的本质及其解决方案。

问题背景

Nginx通过OpenSSL API获取TLS连接中使用的密钥交换组信息，具体涉及两个关键变量：

• $ssl_curves：客户端支持的曲线/组列表
• $ssl_curve：最终协商确定的曲线/组

Nginx传统上使用SSL_get1_curves和SSL_get_negotiated_group获取组标识符，然后通过OBJ_nid2sn转换为可读名称。然而，这种方法对于新的PQC组失效，导致日志中只能显示十六进制代码(如"0x11ec")而非可读名称(如"X25519MLKEM768")。

技术根源

这一问题的根本原因在于OpenSSL 3.5架构的重大改变：

1. 提供者模型：OpenSSL 3.5引入了提供者(provider)机制，允许通过插件方式添加新的加密算法和组
2. NID淘汰：OpenSSL正逐步淘汰传统的NID(数字标识符)机制，新的PQC组不再分配固定的NID
3. API演进：传统的OBJ_nid2sn函数依赖于NID系统，无法处理提供者动态注册的组

解决方案

OpenSSL实际上已经为这种情况准备了替代API：

1. SSL_get0_group_name函数：这是专门设计用于获取组名称的现代API，不依赖NID系统
2. API迁移建议：
   • 弃用SSL_get_negotiated_group和OBJ_nid2sn组合
   • 采用SSL_get0_group_name直接获取可读名称
3. 向后兼容：对于传统EC/NIST曲线，两种方法都能工作，但只有新API能正确处理PQC组

对Nginx的影响与建议

Nginx需要更新其OpenSSL集成代码以支持PQC组：

1. 代码修改：将组名称获取逻辑改为使用SSL_get0_group_name
2. 版本兼容：需要检查OpenSSL版本并选择合适的API
3. 日志完整性：确保所有类型的密钥交换组(包括传统EC、混合PQC和纯PQC)都能正确记录

更广泛的影响

这一变化反映了密码学基础设施的演进：

1. 量子安全过渡：随着PQC的引入，许多传统加密API需要更新
2. 软件生态适配：不仅Nginx，所有依赖OpenSSL进行TLS处理的软件都需要考虑这些API变化
3. 未来兼容性：采用新的提供者友好API将为未来新算法的支持铺平道路

结论

OpenSSL 3.5对PQC的支持是密码学演进的重要里程碑，但也带来了API兼容性挑战。通过采用SSL_get0_group_name等现代API，Nginx等应用可以确保在后量子时代仍能提供完整的日志和诊断信息。这一案例也提醒开发者关注基础加密库的API演进，特别是在重大安全过渡时期。