問題背景

使用阿里雲的WAF時， HTTPS訪問，
偶爾會出現 SSL 建立連接失敗
抓包發現 WAF返回了Encrypted Alert ，然後發了FIN包結束
內容裡頭序號 182~197的包都有異常

問題分析

問題方向確定

問題描述為:抓包發現 WAF返回了Encrypted Alert ，然後發了FIN包結束
分析FIN包是TCP鏈接中斷開時使用的；如圖：

確定該問題不是用戶描述的SSL建立鏈接失敗；而是斷開鏈接有問題。

分析報文

定位用戶描述的報文，如下確實有看到描述的報文，但是該分析方式無法有效的判斷問題：

使用wireshark功能 Follow TCP Stream(追蹤TCP流)觀察條有問題的流報文
可以看到：
A、其中Encrypted Alert與FIN是同時從服務端發送的
B、Encrypted Alert的報文與上一條報文的間隔時間為119.89S
C、No.193的報文客戶端馬上發送了ACK
D、No.194過了14.948客戶端發送了一個RST,ACK報文，重置鏈接
E、No.181與No.191直接沒有任何報文通信

問題定位

總所周知WAF是一個Web應用層面的防護產品，目前WAF的實現訪問是使用Tengine做方向代理。即也會有會話保持時長限制；
而WAF的會話保持時長為120S，與No.181與No.191直接的間隔時間非常相近；建議用戶根據鏈接。

附錄

關於SSL-Encrypted Alert提示

SSL通信在斷開連接時均為發送Encrypted Alert信息給客戶端告知要關閉ssl會話了，同步會發生FIN,ACK報文從TCP層面斷開鏈接:

Since we are already in an encrypted connection, the only way to really know what is being sent within packets is to make Wireshark or similar tools aware of the keys used in the transmission. Even though this is possible, I think for the purpose of this analysis it is enough to know that the client sends an alert message when the connection is asked to be closed actively by the client or server. The type of this Alert message should be CloseNotify (type 0), but we won’t be able to see it from the raw data. In this case, the client is the sender of the following Alert message:

Secure Sockets Layer
    TLSv1.2 Record Layer: Encrypted Alert
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 26
        Alert Message: Encrypted Alert

關於會話時時間

proxy_read_timeout 60s;
 默認：60s
 配在：http中、server中、location中
  在將請求發送給upstream的server後，後端server就會回傳數據，這個時間是兩次收取數據的時間差，不是整個的接收時間。比如說負載大、網絡卡，在第1次收到請求的數據時斷了，然後過了60s後才收到後面的數據，這兩個時間差(其實就是兩次read的時間差)超過了設置的60s，tengine（nginx）就會超時報錯，我當前走的是默認設置60s。
  Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.

WAF-HTTPS [Encrypted Alert]斷開連接