TLS 伺服器正在做一些我不明白的事情。
- TCP握手正常執行。
- SSL Client Hello 正常執行。
- SSL Server Hello 看起來很正常。提供證書,顯示「伺服器問候完成」。
- 剖析顯示客戶端問題“客戶端金鑰交換、更改密碼規範、加密握手訊息”
- 剖析顯示伺服器問題“更改密碼規範”然後是“加密握手訊息”
客戶端現在確認,開始發送資料。但伺服器 ACK 隨後發送「加密警報」並且 FIN 發出。
這是在交換證書後發生的。 SSL 握手中提供的憑證是新金鑰。
線索,有人嗎?
答案1
這可能是由於客戶端或中間某些設備(例如負載平衡器)的 SNI 問題造成的。負載平衡設備必須能夠將伺服器名稱作為初始用戶端問候的一部分呈現給後端主機。看https://en.m.wikipedia.org/wiki/Server_Name_Inspiration
答案2
最重要的資料包是“加密警報”,因為它包含連接關閉的原因。
這似乎是一個驗證錯誤。這意味著該證書不受信任或無效。但真正的原因是透過TLS 警報協議
答案3
pure-ftpd
我在顯式 TLS 模式(FTPS 伺服器)中遇到了類似的問題。
但就我而言,有不 Encrypted Alert
從伺服器發送;它只是在金鑰交換後立即Find(Change Cipher Spec, Finished
來自伺服器的訊息→來自伺服器的FIN)。下一個,客戶端發送了Encrypted alert
1 級代碼 0 Close Notify
(這是預期的 — 與伺服器 FIN 不同)。
這種情況僅發生在一個特定客戶端(裝置韌體)上,並且不會在其他 ftps 用戶端上重現。
我還沒有找出問題的根源,但我懷疑我們遇到了問題伺服器錯誤。pure-ftpd
使用類似 apache fork-per-connection 模型;我觀察到子進程崩潰在 gdb 中(以代碼 -1 退出)—這當然會導致作業系統關閉套接字 FD 並發送 FIN。
在我的例子中,還有一個理由說它是伺服器錯誤——一旦我們將 ftps 伺服器換成不同的實現,該行為就停止再現proftpd
。
我認為這與 OP 情況不符——伺服器以 TLS 適當的方式結束連接,並帶有加密警報——但無論如何,任何點擊此頁面的人都需要考慮一些事情。