沙雕發信服務器引起的TLS思考

背景：

某發信服務器在發信日誌裏一直顯示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進行從新發送）

新發現：

在出現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 不匹配  （檢查本身並無校驗服務器名稱和證書的匹配狀況）

再次驗證：

既然QQ郵箱能夠發送成功，那麼QQ郵箱對TLS的支持是怎樣的呢？

對smtp.qq.com 進行TLS測試，發現默認使用的是TLS1.2

那麼對TLS v1.0 支持狀況如何呢？ checktls.com 支持指定TLS 版本、TLS加密協議進行測試。

在測試選項裏，自定義TLS版本

測試證實，QQ郵箱支持TLS v1.0

那麼沙雕服務器的TLS版本支持狀況如何？同樣拿這個工具測試（參考前面的圖能夠看出對方應該只支持v1.0 也就是TLSv1)

優化配置:

這個note 小字部分，不看還好，看的時候誤讓我理解爲TLSv1.2 不能和v1.0 同時存在，只能v1.2和v1.1 或者v1.1和v1.0 這樣的組合。結果實際意思是TLS v1.0 和TLS1.2 一塊兒存在時，必須要啓用V1.1 ，尼瑪…………..英文很差就要被歧視

發自靈魂的再次拷問：

就算QQ郵箱的TLS是可選項、沙雕服務器的TLS也是可選項，QQ郵箱也支持TLSv1.0 ,那麼爲何QQ郵箱仍是走了非TLS傳輸呢（參見背景部分的QQ郵箱郵件頭的分析），鑑於沙雕服務器的一股清流操做，它不會重試，請問它是如何辦到的呢？

欲知後事如何：

請等個人最終抓包圖，等待沙雕服務器發送鏈接可能要一週，運氣好可能改天