Boulder项目中关于Go 1.22移除RSA密钥交换的应对方案

在Go 1.22版本中，默认禁用了使用RSA密钥交换(RSA KEX)的加密套件，这一变更对Boulder项目中的TLS-ALPN-01和HTTP-01验证请求产生了潜在影响。本文将深入分析这一变更的技术背景、影响范围以及Boulder团队采取的应对策略。

技术背景

RSA密钥交换是一种传统的TLS握手机制，它允许客户端使用服务器的RSA公钥来加密预主密钥(pre-master secret)。随着密码学的发展，更安全的前向保密(Forward Secrecy)密钥交换机制如ECDHE和DHE逐渐成为主流。Go语言团队决定在1.22版本中默认禁用RSA KEX，这是推动现代加密标准的重要一步。

影响分析

这一变更主要影响Boulder项目中的两个核心功能：

1. TLS-ALPN-01验证：用于验证域名控制权的TLS扩展验证方式
2. HTTP-01验证：通过HTTP协议进行的验证，特别是当使用HTTPS重定向时

禁用RSA KEX可能导致与某些老旧服务器的兼容性问题，这些服务器可能仍依赖RSA密钥交换机制。

解决方案演进

Boulder团队最初考虑了两种应对方案：

1. 通过crypto/tls.Config.CipherSuites显式重新启用RSA KEX套件
2. 使用GODEBUG环境变量tlsrsakex=1作为临时解决方案

经过深入讨论，团队决定采用更系统化的方法：

1. 在日志中添加"usedRSAKEX"字段到va.go的validationRequestEvent中
2. 对于HTTP-01验证，直接从http.Response对象获取TLS ConnectionState

实施挑战

主要的实施难点在于如何从各个验证函数中提取额外的元数据，并将其传递到VA顶层，以便记录到日志事件中。这需要对现有的验证流程进行一定程度的改造。

当前状态与未来计划

目前，相关工作已经完成，团队收集到了相关数据。数据显示，虽然绝对数量上仍有一定比例的RSA KEX使用，但相对比例已经非常小。接下来的计划是：

1. 设置tlsrsakex=1环境变量
2. 升级到Go 1.22.1版本
3. 正式宣布RSA KEX的弃用计划
4. 观察数周后，最终移除环境变量支持

这一渐进式的过渡方案既保证了系统的稳定性，又为最终完全移除RSA KEX支持提供了充足的时间窗口。

总结

Boulder项目对Go 1.22中RSA KEX变更的响应体现了开源项目对安全性和兼容性的平衡考量。通过细致的监控和分阶段的实施计划，确保了服务平稳过渡到更现代的加密标准。这一案例也为其他面临类似升级挑战的项目提供了有价值的参考。