H2O项目中Neverbleed与BoringSSL的兼容性问题解析

背景介绍

在H2O高性能HTTP服务器项目中，Neverbleed是一个重要的安全组件，它通过将私钥操作隔离到独立的特权进程中，有效降低了私钥泄露的风险。而BoringSSL则是Google维护的OpenSSL分支，提供了更现代的SSL/TLS实现。

问题发现

当H2O服务器同时使用Neverbleed和BoringSSL时，存在一个兼容性问题。具体表现为：H2O原本的设计是为BoringSSL分配一个单一的SSL_PRIVATE_KEY_METHOD，并通过SSL对象获取RSA密钥。然而，随着BoringSSL的更新（特别是a792f8804773f9c6c8fa55a8d9a502d56bd79b2b这个提交），这种实现方式不再有效。

技术原因

问题的根源在于BoringSSL引入的SSL_CREDENTIAL对象机制。这个用于保存私钥的对象无法同时保留密钥方法和pkey（公钥/私钥对）。在BoringSSL的新架构中，密钥操作方法和密钥本身被视为互斥的两种凭证类型。

解决方案

经过技术分析，正确的修复方案应该是：

1. 停止使用EVP_PKEY这种统一的密钥接口
2. 为每个私钥创建独立的密钥方法实例
3. 特别处理BoringSSL与Neverbleed同时使用的情况

值得注意的是，根据SSL_set_private_key_method的文档说明，调用者还应该通过SSL_set_signing_algorithm_prefs配置签名能力。否则BoringSSL可能会选择密钥方法不支持的签名算法。

实现细节

在实际修复中，开发团队调整了neverbleed_load_private_key_file函数的实现，使其在检测到BoringSSL环境时：

1. 为每个私钥生成独立的密钥方法实例
2. 将这些方法直接分配给SSL_CTX对象
3. 考虑BoringSSL的异步模式特性（这部分可能更适合作为H2O而非Neverbleed的功能）

总结

这个问题展示了现代加密库演进过程中可能出现的兼容性挑战。通过深入理解BoringSSL的凭证管理机制，H2O团队找到了既保持安全性又不牺牲性能的解决方案。这种对底层加密库变化的快速响应，体现了H2O项目对安全性和稳定性的高度重视。