背景:

某发信服务器在发信日志里一直显示TLS Fail 看protocal log 发现一直出现“454 TLS not available due to temporary reason” 错误,也有其他的服务器出现类似错误,但是其他服务器接着会重试,使用非TLS连接发送成功。这个服务器它只尝试一次就会放弃,和常见邮件发送服务器的行为多次尝试重发相比,简直就是一股清流。但是这个服务器发往QQ邮箱的邮件可以收到。


信息2:因为邮件头信息中会显示关于TLS的信息,所以我把QQ邮箱里的邮件头弄了出来,发现QQ邮箱的邮件传输是没有走TLS的。

初步判断:

1. 没有重传机制,这个是致命伤。

2. 对方服务器的TLS肯定在某个地方有问题。可能是证书没有配置好、可能是网络问题导致证书协商失败。

初步解决:

1. 查到对方的发信IP地址只有一个,我把该服务器IP的TLS传输强制设置为非加密。问题解决,可以收到信了,似乎到此就该结束了。但我还是有个疑问没有解决,为什么QQ邮箱的就成功了,腾讯的邮箱也是使用了TLS Prefer,就是你用STARTTLS 对方就会尝试TLS 加密,如果不支持TLS就走非加密,那么为什么和QQ邮箱协商成功了呢。QQ邮箱不可能对该地址做特殊设置的。

尝试解释454 错误:

“454 TLS not available due to temporary reason”出现的原因是什么,这个疑问一直在脑子里转悠,搜索引擎搜的内容里面,基本没有对这个问题进行详细解释,RFC也是一笔带过的解释了下454 代码的意思。所以我只能通过抓包对比来发现问题所在。


下图是我抓包看到的同样出现过454 TLS not available temprorary reason的其他服务器的行为,和沙雕服务器相比,就多了个使用非TLS重试的动作,其他似乎找不到原因了:

1. Client Hello 后,我方回复454

2. 但是对方可能没有意识到,又接着发来了识别不了的Command

3. 我方看到识别不了的command ,断开连接

4. 对方重新传输 (包50351 开始重新握手到50371 之间使用非TLS进行重新发送)


image

新发现:

在出现454 代码之前,仅有一个Client Hello 的交互,难道是这个地方出问题了么?对方的证书是不是有问题?带着这个问题,我使用了一个测试ssl的网站(非常的棒,这个工具在后续发挥了很大的作用)

https://www.checktls.com/TestReceiver


对对方服务器进行了测试,发现了几个关键点:

1. 对方支持TLS协商,TLS是可选项

2. SSL 版本是v1.0    (检查自己的TLS版本支持配置,仅勾选了V1.1和V1.2,这个是454 TLS not available due to temporary reason的真正原因么?)

3. 对方的证书和hostname 不匹配  (检查自己并没有校验服务器名称和证书的匹配情况

image

再次验证:

既然QQ邮箱可以发送成功,那么QQ邮箱对TLS的支持是怎样的呢?

对smtp.qq.com 进行TLS测试,发现默认使用的是TLS1.2

image

那么对TLS v1.0 支持情况如何呢? checktls.com 支持指定TLS 版本、TLS加密协议进行测试。

在测试选项里,自定义TLS版本

image

测试证明,QQ邮箱支持TLS v1.0

image


那么沙雕服务器的TLS版本支持情况如何?一样拿这个工具测试(参考前面的图可以看出对方应该只支持v1.0 也就是TLSv1)


优化配置:

这个note 小字部分,不看还好,看的时候误让我理解为TLSv1.2 不能和v1.0 同时存在,只能v1.2和v1.1 或者v1.1和v1.0 这样的组合。结果实际意思是TLS v1.0 和TLS1.2 一起存在时,必需要启用V1.1 ,尼玛…………..英文不好就要被歧视

image

发自灵魂的再次拷问:

就算QQ邮箱的TLS是可选项、沙雕服务器的TLS也是可选项,QQ邮箱也支持TLSv1.0 ,那么为什么QQ邮箱还是走了非TLS传输呢(参见背景部分的QQ邮箱邮件头的分析),鉴于沙雕服务器的一股清流操作,它不会重试,请问它是如何办到的呢?

欲知后事如何:

请等我的最终抓包图,等待沙雕服务器发送连接可能要一周,运气好可能改天