Rustls项目中TLS 1.3签名方案扩展性问题解析

在Rustls这个Rust语言实现的TLS库中，开发者发现了一个关于TLS 1.3协议签名方案(SignatureScheme)扩展性的重要问题。这个问题主要影响那些希望为Rustls添加自定义加密算法的开发者，特别是涉及后量子密码学(PQC)算法的场景。

问题背景

Rustls作为一个现代化的TLS实现，其设计目标之一就是保持高度的安全性和灵活性。然而，在TLS 1.3的实现中，签名方案的处理机制存在一定的局限性。当开发者尝试集成自定义的签名算法(如ML-DSA等后量子签名方案)时，会遇到服务器端无法识别客户端提供的签名方案的问题。

技术细节分析

问题的核心在于Rustls服务器端对TLS 1.3签名方案的处理逻辑。当前实现采用了一个白名单机制，只允许预先定义在SignatureScheme::supported_in_tls13()中的签名方案。这意味着：

1. 任何自定义的SignatureScheme::Unknown变体都会被服务器端过滤掉
2. 即使客户端正确广告了新的签名方案，服务器也无法识别
3. 最终导致握手失败，抛出PeerIncompatible(NoSignatureSchemesInCommon)错误

解决方案演进

Rustls维护团队迅速响应并提出了两种改进方案：

1. 直接扩展枚举方案：为需要的签名方案添加新的枚举变体，并确保它们在supported_in_tls13()中被启用。这种方法简单直接，但缺乏长期扩展性。

2. 更灵活的拒绝列表方案：将当前的白名单机制改为黑名单机制，只排除已知不安全的算法(如使用SHA1的签名方案和RSA-PKCS1)，而默认允许其他方案。这种方法更具前瞻性，为未来新算法的集成提供了更好的支持。

实际影响与修复

Rustls团队最终采用了第二种更灵活的方案，这一变更已经包含在0.23.26版本中发布。这一改进意味着：

• 开发者现在可以更轻松地集成自定义签名方案
• 后量子密码学算法的实验性集成变得更加可行
• 系统保持了向后兼容性，不会影响现有功能

对开发者的建议

对于需要在Rustls中使用自定义签名方案的开发者，现在可以：

1. 确保使用Rustls 0.23.26或更高版本
2. 按照标准方式定义自己的SignatureScheme枚举变体
3. 实现相应的CryptoProvider接口
4. 无需担心服务器端会过滤掉自定义方案

这一改进显著提升了Rustls在密码学算法演进方面的适应能力，特别是在后量子密码学过渡时期，为研究和实验提供了更好的支持。