Rustls项目中密钥与证书一致性验证的实现

在Rustls项目中，一个重要的安全特性是确保客户端或服务器使用的私钥与其证书中的公钥相匹配。本文将深入探讨这一功能的实现原理和技术细节。

背景与需求

在TLS/SSL通信中，证书和私钥的配对至关重要。证书包含公钥信息，而私钥则用于签名操作。如果这两者不匹配，将导致握手失败。传统上，OpenSSL提供了X509_check_private_key函数来验证这种一致性。

Rustls作为一个现代化的TLS实现，也需要类似的验证机制，但需要更符合Rust生态的设计。这种验证不仅能提高安全性，还能在早期发现配置错误。

技术实现方案

Rustls团队经过讨论，确定了分阶段实现的方案：

1. webpki扩展：首先在webpki库中为EndEntityCert类型添加功能，使其能够以标准SPKI(SubjectPublicKeyInfo)格式公开证书的公钥。

2. 签名密钥接口扩展：在rustls::sign::SigningKey特性中添加public_key方法，返回密钥对的公钥部分，同样采用SPKI格式。考虑到某些实现可能无法提供此功能，设计为可选返回。

3. CertifiedKey验证：在CertifiedKey结构中添加验证方法，执行以下操作：

   • 解析终端实体证书获取SPKI
   • 从私钥获取对应的SPKI
   • 比较两者是否匹配

4. 自动验证集成：在各种证书设置函数(如set_single_cert)中自动调用验证逻辑。

实现细节与挑战

实现过程中面临几个技术挑战：

1. SPKI格式处理：webpki内部表示缺少长度前缀，需要重构为完整SPKI格式。这涉及到pki-types中新类型的引入。

2. 密钥提供者支持：需要为不同后端(ring、aws-lc-rs等)实现公钥提取功能，这需要对各加密库API进行深入研究。

3. 错误处理设计：需要设计清晰的错误类型，区分证书解析失败、公钥提取失败和密钥不匹配等不同情况。

4. 性能考量：验证操作会增加初始化开销，需要评估对性能的影响。

安全考虑

值得注意的是，这种验证仅检查公钥材料(如RSA的模数和指数)或密钥参数(如EC参数)是否匹配。它不会验证提供的密钥是否确实是私钥而非公钥。这与OpenSSL的行为保持一致，提供了合理的灵活性。

向后兼容性

该功能的引入确实导致了某些行为变化，特别是当证书包含标记为关键的扩展时，验证过程会更加严格。对于需要保持旧行为的用户，建议使用with_client_cert_resolver而非with_client_auth_cert，这样可以绕过自动验证。

总结

Rustls通过这一系列改进，提供了更健壮的密钥-证书验证机制，增强了TLS实现的安全性。这种分层设计既保持了灵活性，又确保了基本的安全检查，体现了Rustls项目对安全性和可用性的平衡考虑。