CouchDB SSL/TLS 密钥交换安全性增强方案

问题背景

在CouchDB 3.2.2版本中，安全扫描工具发现存在SSL/TLS密钥交换方面的改进空间(QID-38863)。该问题源于服务器配置允许使用安全性较低的密钥交换算法。根据安全标准要求，密钥交换应提供至少112位的安全强度，这意味着：

• 对于Diffie-Hellman(DH)或RSA密钥交换，密钥大小至少应为2048位
• 对于椭圆曲线Diffie-Hellman(ECDH)密钥交换，密钥大小至少应为224位

技术分析

CouchDB的配置文件(local.ini)目前仅支持指定密码套件(cipher suites)，但缺乏直接配置ECC曲线(椭圆曲线)的选项。虽然用户已在Windows Server注册表的SChannel中配置了强TLS/SSL交换密钥，但CouchDB并未加载这些ECC曲线。

通过sslscan工具检测发现，CouchDB当前加载了部分安全性较低的交换密钥，包括：

• 较旧的椭圆曲线(如secp160k1, secp160r1等)
• 安全性较低的Diffie-Hellman交换参数

临时解决方案

在官方修复发布前，推荐以下两种临时解决方案：

方案一：使用反向代理

1. HAProxy方案：

   • 在CouchDB前端部署HAProxy
   • 在HAProxy中配置强TLS参数和ECC曲线
   • 让HAProxy处理TLS终止，然后以明文与CouchDB通信

2. IIS反向代理方案：

   • 配置IIS作为CouchDB的前端代理
   • 在IIS中设置强TLS参数
   • 将HTTPS请求通过IIS转发到后端的CouchDB

方案二：加强现有配置

在local.ini中添加以下配置，至少确保只使用TLS 1.2：

[ssl]
tls_versions = ['tlvs1.2']

长期解决方案

CouchDB开发团队已确认这是一个需要代码增强的问题。预计该修复将包含在未来的3.4.1版本中。修复将包括：

1. 在SSL配置节中添加ECC曲线指定选项
2. 默认禁用安全性较低的交换算法
3. 提供更细粒度的TLS参数控制

最佳实践建议

1. 定期更新CouchDB到最新稳定版本
2. 使用专业工具(如sslscan)定期检查TLS配置
3. 在生产环境始终使用反向代理处理TLS终止
4. 遵循最小权限原则，只启用必要的加密算法
5. 建立定期的安全审计机制

对于无法立即升级的环境，强烈建议采用反向代理方案作为过渡措施，这不仅能解决当前密钥交换问题，还能提供额外的安全层和灵活性。