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

在Rustls项目中，开发者发现了一个关于TLS 1.3协议中签名方案(SignatureScheme)扩展性的重要问题。这个问题主要出现在尝试为Rustls添加后量子密码学(PQC)算法支持时，特别是当开发者尝试集成liboqs库中的ML-DSA签名算法时。

问题背景

Rustls是一个用Rust编写的现代化TLS库，以其安全性和性能著称。在TLS 1.3协议中，签名方案的选择是一个关键环节，它决定了客户端和服务器之间如何进行身份验证和数据完整性保护。

当开发者尝试为Rustls添加自定义的密码学提供程序(CryptoProvider)，以支持后量子签名算法ML-DSA时，发现服务器端无法正确处理客户端提供的自定义签名方案。具体表现为服务器会返回"PeerIncompatible(NoSignatureSchemesInCommon)"错误，导致握手失败。

问题根源分析

深入分析Rustls源代码后发现，问题的核心在于服务器端对TLS 1.3签名方案的处理逻辑。在当前的实现中，服务器端会通过一个名为supported_in_tls13()的方法对客户端提供的签名方案进行过滤，只保留预定义在白名单中的方案。

这种设计导致了以下问题：

1. 任何自定义的签名方案(使用SignatureScheme::Unknown变体)都会被自动过滤掉
2. 服务器无法识别客户端提供的后量子签名方案
3. 扩展性受限，无法灵活添加新的签名算法

解决方案

Rustls维护团队迅速响应并提出了两种解决方案思路：

1. 直接扩展法：在SignatureScheme枚举中显式添加所需的签名方案变体，并确保它们在supported_in_tls13()中被正确启用。

2. 更灵活的拒绝列表法：将当前的允许列表模式改为拒绝列表模式。拒绝列表只需要包含不安全的算法(如使用SHA1的算法和RSA-PKCS1)，而其他算法则默认允许。这种方法提供了更好的扩展性，使未来添加新算法更加容易。

维护团队最终选择了第二种方案，因为它提供了更好的长期扩展性。这个变更已经通过拉取请求实现，并在Rustls 0.23.26版本中发布。

技术影响

这一变更对Rustls项目具有重要意义：

1. 更好的扩展性：现在开发者可以更容易地为Rustls添加新的签名算法支持，特别是后量子密码学算法。

2. 安全性保持：通过拒绝列表而非允许列表，在保持安全性的同时提高了灵活性。拒绝列表只需要关注已知不安全的算法。

3. 后量子密码学支持：这一变更为Rustls支持ML-DSA等后量子签名算法扫清了道路，为应对未来的量子计算威胁做好准备。

开发者建议

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

1. 确保使用Rustls 0.23.26或更高版本
2. 自定义签名方案不再会被自动过滤
3. 仍需确保实现的签名算法满足TLS协议的安全要求

这一改进展示了Rustls项目对安全性和扩展性的持续关注，同时也体现了开源社区快速响应和解决问题的能力。对于关注TLS协议实现和后量子密码学的研究人员和开发者来说，这无疑是一个积极的进展。