通过AWS NLB访问SMTP服务发送RCPT TO时出现RENEGOTIATING错误的原因
2026-7-9
问题描述
我将SMTP服务部署在ECS Fargate上，通过采用TLS 1.2的Network Load Balancer（NLB）对外提供服务，服务使用标准SMTP协议与客户端通信。
通过openssl工具测试时：
- 本地直接测试Fargate服务及在Fargate内部测试均正常，执行流程如下：
$openssl s_client -connect xxx.com:443 HELO 250 OK MAIL FROM:AAA@BB.COM 250 OK QUIT 250 OK
- 但通过NLB访问时，所有以字符R开头的SMTP命令（如
RCPT TO:）均无法正常执行，会出现RENEGOTIATING提示后连接关闭，本地直接测试无此问题，测试流程如下：
$openssl s_client -connect mynlbhost.tampabayclosure.com:443 HELO 250 Hello MAIL FROM:AA@BB.com 250 OK RCPT TO:BB@CC.com RENEGOTIATING write:errno=54
已尝试使用openssl s_client -connect host:port -no_renegotiation及openssl s_client -connect host:port -no_renegotiation -tls1_2命令，均未解决问题。
请问该问题的原因是什么？
问题原因分析
- NLB的TLS终止逻辑误触发重协商：AWS NLB在TLS 1.2模式下的连接处理逻辑中，可能把以R开头的SMTP命令（如
RCPT TO:）的首字节特征误判为TLS重协商请求的触发信号，主动发起TLS重协商。而Fargate上的SMTP服务未适配这种场景，无法响应重协商请求，最终导致连接中断。 - SMTP服务的TLS重协商配置不兼容：虽然直接访问服务时无问题，但NLB作为中间代理改变了TLS连接的上下文。SMTP服务可能未启用TLS重协商支持，或者其重协商参数与NLB的TLS行为不匹配。即便客户端通过
-no_renegotiation禁用了重协商，NLB仍可能主动触发该操作，引发连接失败。 - NLB的协议检测机制存在兼容性问题：NLB底层的协议检测逻辑对SMTP协议的适配存在缺陷，将正常的SMTP命令字节模式误识别为异常TLS操作触发条件，在TLS 1.2环境下这种误判概率更高，导致连接异常断开。
内容的提问来源于stack exchange，提问作者Lester Gray
相关产品推荐
相关产品推荐
