Axon项目中的Req库在OTP 26下的HTTPS证书验证问题解析

在Elixir生态系统中，Axon项目作为神经网络构建工具，其示例代码经常需要从互联网下载数据集。近期随着OTP 26的发布，默认的SSL/TLS证书验证行为发生了变化，这直接影响了Axon项目中基于Req库的网络请求功能。

问题背景

OTP 26对SSL/TLS模块进行了重要更新，将客户端默认的verify选项从:verify_none改为:verify_peer。这一变更增强了安全性，但同时也导致了一些网站（如gutenberg.org）的证书验证失败。这是因为这些网站的证书链中包含了使用SHA-1签名算法的证书，而OTP 26默认不再支持这种较弱的签名算法。

技术分析

在OTP 26环境下，当尝试通过Req库访问某些网站时，会遇到"Bad Certificate"错误。这并非Req库本身的缺陷，而是OTP安全策略升级的结果。通过深入分析发现：

1. 现代TLS安全标准已逐步淘汰SHA-1等弱签名算法
2. 部分老牌网站（如gutenberg.org）的证书链尚未完全更新
3. OTP 26严格执行了最新的安全标准

解决方案

针对这一问题，Axon项目可以考虑以下几种解决方案：

方案一：使用tls_certificate_check库

options = [transport_opts: tls_certificate_check:options('example.com')]
Req.get!("example.com", connect_options: options)

这种方法提供了更精细的证书验证控制，同时保持较高的安全性。

方案二：调整签名算法配置

options = [
  transport_opts: [
    signature_algs_cert: :ssl.signature_algs(:default, :"tlsv1.3") ++ [sha: :rsa]
  ]
]
Req.get!("https://www.gutenberg.org", connect_options: options)

此方案通过扩展支持的签名算法列表来解决兼容性问题。

方案三：结合校验和与宽松验证

options = [transport_opts: [verify: :verify_none]]
Req.get!("https://www.gutenberg.org", 
         connect_options: options, 
         checksum: "md5:5f72f1f7bdee16a64e26b46cf2e7c40f")

这种方法虽然降低了验证强度，但通过校验和确保了数据完整性。

最佳实践建议

对于Axon项目中的示例代码，建议：

1. 优先考虑方案一，因为它提供了最佳的安全性和兼容性平衡
2. 在示例文档中明确说明HTTPS连接的安全配置
3. 对于教育性质的示例代码，可以适当放宽验证要求，但应添加清晰的注释说明
4. 考虑为常用数据源提供本地缓存版本，减少对外部服务的依赖

总结

OTP 26的安全升级反映了现代网络安全的最佳实践。作为开发者，我们应当理解这些变化背后的安全考量，并在安全性和兼容性之间找到适当的平衡点。对于Axon项目而言，这既是一个技术挑战，也是一个提升项目安全性的机会。