AWS s2n-tls 对 TLS 1.2 中 RSA-PSS 证书支持的技术解析

在 TLS 协议演进过程中，RSA-PSS（Probabilistic Signature Scheme）签名方案作为传统 PKCS#1 v1.5 签名方案的替代品，提供了更强的安全保证。AWS 开源 TLS 实现 s2n-tls 目前对 RSA-PSS 证书在 TLS 1.2 协议中的支持存在限制，这引发了关于协议兼容性和实现规范性的技术讨论。

背景与问题分析

s2n-tls 当前实现将 rsa_pss_pss 签名算法的最低协议版本限制为 TLS 1.3，这源于对 RFC 8446 条款的特定解读。该 RFC 指出，实现如果声明支持 RSASSA-PSS（在 TLS 1.3 中是强制要求），则必须准备接受使用该方案的签名，即使协商的是 TLS 1.2 版本。

技术团队最初的理解存在偏差，认为该要求仅适用于 rsa_pss_rsae（使用传统 RSA 证书配合 PSS 填充）场景，而非 rsa_pss_pss（使用 RSA-PSS 证书配合 PSS 填充）场景。然而，通过 OpenSSL 的互操作性测试证实，主流实现实际上支持在 TLS 1.2 中使用 RSA-PSS 证书配合 RSA 认证的密码套件。

技术规范解读

深入分析相关 RFC 规范可以明确以下几点关键要求：

1. 在 TLS 1.2 环境中，当使用 RSA 认证的密码套件时，RSA-PSS 证书应当被允许作为认证凭据
2. 对于客户端认证场景，由于不涉及密码套件的认证类型限制，RSA-PSS 证书应当无条件支持
3. RSA-PSS 证书不能用于 RSA 密钥交换（RSA kex），这是 RSA-PSS 设计的基本特性

实现方案设计

针对 s2n-tls 的改进方案需要考虑以下技术要点：

1. 协议版本兼容性：移除 rsa_pss_pss 签名算法的 TLS 1.3 最低版本限制
2. 密码套件协同工作：确保 RSA-PSS 证书仅在与 RSA 认证兼容的密码套件中使用
3. 密钥交换限制：明确禁止 RSA-PSS 证书用于 RSA 密钥交换场景
4. 客户端认证支持：完善对 RSA-PSS 客户端证书的处理逻辑

技术影响评估

该改进将带来以下技术影响：

1. 协议层面：服务器将在 TLS 1.2 证书请求消息中提供 rsa_pss_pss 签名算法选项
2. 兼容性：提升与其它 TLS 实现的互操作性，符合主流实现行为
3. 安全性：扩展支持更安全的签名方案而不降低协议安全性
4. 遗留系统：需考虑与 OpenSSL 1.0.2 等不支持 RSA-PSS 证书的旧版 libcrypto 的兼容处理

实施注意事项

在具体实现过程中需要特别关注：

1. 证书验证逻辑需要正确处理 RSA-PSS 特有的参数（如哈希算法和掩码生成函数）
2. 签名验证流程需要适应 PSS 填充方式的特性
3. 错误处理需要明确区分传统 RSA 和 RSA-PSS 证书的处理路径
4. 测试覆盖需要包括各种组合场景（不同哈希算法、不同密钥长度等）

总结

通过对 s2n-tls 的这项改进，项目将更全面地支持现代密码学标准，提升协议实现的规范性和互操作性。这一变化虽然不涉及公共 API 的修改，但对协议握手过程有实质影响，需要充分的测试验证来保证实现的正确性和稳定性。对于使用 s2n-tls 的开发者和终端用户而言，这一改进意味着更广泛的证书类型支持和更符合标准的行为表现。