s2n-tls项目在OpenSSL 3.0 FIPS模式下的签名问题分析

在s2n-tls项目中，我们发现了一个与OpenSSL 3.0 FIPS模式相关的签名兼容性问题。这个问题与之前awslc-fips中遇到的签名问题类似，但解决方案更为复杂。

问题背景

在TLS协议中，证书验证和密钥交换过程中需要对数据进行签名。传统上，这个过程可以分为两步：首先对数据进行哈希处理，然后使用私钥对哈希结果进行签名。然而，在FIPS模式下，特别是FIPS 140-3标准中，这种分离的操作方式不再被允许。

技术挑战

OpenSSL 3.0 FIPS实现要求签名操作必须使用EVP_DigestSignInit函数，而不是先单独计算哈希再签名。这带来了几个技术难点：

1. 数据时序问题：在TLS握手过程中，我们通常先有需要签名的数据，然后才能确定使用哪个私钥进行签名。但EVP_DigestSignInit要求提前知道私钥。

2. 内存消耗：对于TLS 1.2的证书验证消息，需要签名的是完整的握手消息而不仅仅是其哈希值。这意味着在确定使用哪个私钥前，必须保存所有原始握手消息。

3. pkey offloading特性：在某些情况下，我们可能永远不会拥有私钥（当使用pkey offloading特性时），这使得直接使用EVP_DigestSignInit变得困难。

解决方案探讨

我们考虑了以下几种可能的解决方案：

1. 回调机制：在async_pkey逻辑中添加回调，延迟哈希计算。这样可以在拥有私钥后再更新哈希状态。

2. 传递原始数据：修改pkey操作接口，使其接收原始数据而非哈希状态。这样可以在签名时调用EVP_DigestSignInit。

3. 完整消息存储：对于TLS 1.2证书验证，存储完整的握手消息直到确定签名密钥。

经过深入分析，我们发现OpenSSL 3.0 FIPS目前仅获得FIPS 140-2认证，而上述限制主要来自FIPS 140-3标准。因此，我们可以暂时沿用awslc-fips的解决方案，同时记录未来需要为FIPS 140-3支持所做的工作。

性能与安全考量

存储完整握手消息虽然解决了技术问题，但会带来额外的内存开销。对于TLS 1.3，这种开销相对较小（约200字节），但对于TLS 1.2，可能需要存储所有握手消息。不过考虑到这些消息主要来自可信的服务器端（ClientHello除外），安全风险相对可控。

结论与建议

当前最佳实践是：

1. 对于OpenSSL 3.0 FIPS 140-2模式，继续使用现有的解决方案
2. 记录未来需要为FIPS 140-3支持所做的工作
3. 在pkey offloading场景下，限制私钥配置以避免复杂情况

这个案例展示了密码学库升级过程中可能遇到的兼容性挑战，特别是在涉及严格安全标准如FIPS时。开发团队需要在安全性、兼容性和性能之间做出平衡决策。