HAProxy项目中的HTTP/3在OpenBSD arm64平台上的兼容性问题分析

在HAProxy项目中，开发人员发现了一个关于HTTP/3协议在OpenBSD arm64平台上无法正常工作的问题。这个问题表现为当使用LibreSSL作为TLS后端时，特定的加密套件会导致通信失败，而同样的配置在OpenBSD amd64平台上却能正常工作。

问题现象

当在OpenBSD arm64系统上运行HAProxy并启用HTTP/3支持时，客户端使用curl进行连接会收到ERR_DRAINING错误。经过深入排查，发现问题与特定的TLS 1.3加密套件有关：

• TLS_AES_128_GCM_SHA256：工作正常
• TLS_AES_256_GCM_SHA384：工作正常
• TLS_CHACHA20_POLY1305_SHA256：导致连接失败
• TLS_AES_128_CCM_SHA256：导致连接失败

根本原因分析

通过添加调试代码和测试，开发团队发现问题的根源在于HAProxy无法解密自己加密的数据包。这种现象仅在以下组合中出现：

1. 使用LibreSSL作为TLS后端
2. 使用TLS_CHACHA20_POLY1305_SHA256加密套件
3. 运行在OpenBSD arm64平台

进一步的测试表明，当使用QuicTLS或OpenSSL替代LibreSSL时，问题不会出现。这强烈表明问题与LibreSSL在特定平台上的实现有关。

技术细节

在加密过程中，HAProxy使用AEAD（Authenticated Encryption with Associated Data）算法进行数据加密。测试发现，当使用TLS_CHACHA20_POLY1305_SHA256套件时：

1. HAProxy能够成功加密数据包
2. 但无法解密自己刚刚加密的数据包
3. 这导致通信流程中断，最终表现为连接超时

特别值得注意的是，这个问题在OpenBSD amd64平台上不易被发现，因为该平台通常会优先选择AES-GCM系列加密套件（可能由于硬件加速支持），而arm64平台则更倾向于选择CHACHA20-POLY1305。

解决方案

目前确认的临时解决方案包括：

1. 强制使用AES-GCM系列加密套件（TLS_AES_128_GCM_SHA256或TLS_AES_256_GCM_SHA384）
2. 使用QuicTLS或OpenSSL替代LibreSSL作为TLS后端

对于长期解决方案，可能需要：

1. 深入分析LibreSSL在arm64平台上对CHACHA20-POLY1305的实现
2. 检查可能的字节序或内存对齐问题
3. 与LibreSSL开发团队协作修复底层问题

结论

这个问题展示了在不同硬件平台和加密后端组合下可能出现的微妙兼容性问题。对于生产环境中使用HAProxy和HTTP/3的用户，建议：

1. 在arm64平台上明确指定支持的加密套件
2. 进行全面测试以验证所有加密套件的兼容性
3. 考虑使用经过验证的TLS后端组合

该问题的发现和解决过程也凸显了全面跨平台测试的重要性，特别是在涉及新协议和加密算法时。