IIS Web Service 也算是一個主流的HTTP服務軟體，有不少MS系的應用在IIS上運作、也有使用者使用IIS提供的平台運作他們.Net Framework開發的應用程式。當然，為了網站安全，不少使用者選擇在IIS server前放一層WAF避免攻擊。而這次，我們的一個使用者遇到了一個有意思的問題，
問題現象
IIS Web service，上面運作了許多網站應用程式，以SNI區分。在IIS伺服器之前放置一層WAF回源。使用者回報，有個IIS Web site通過WAF回源不成功。
現象主要是 在通路網站的時候，浏覽器一直在加載，傳回502/504等錯誤碼，同時伴有499錯誤。
排查過程
由于IIS Web service對于我們來說基本上是一個黑盒，且在問題發生的時候基本沒有任何錯誤日志和通路日志，我們基本上采用大膽猜測小心求證的方案來一步步定位問題。作為一整套系統，問題無非出在這幾個方面，
網絡問題
所有涉及到的IP及其對應端口我們都測試了聯通性，telnet/tcpping等都顯示連接配接三次握手正常。
IIS伺服器本身問題
通過對IIS 伺服器直接通路，我們基本排除伺服器處理問題。（以下是我們測試主機的通路記錄）
curl -v
https://hello.test.domain:8443/-o /dev/null -s --trace-time --resolve hello.test.domain:8443:ip.add.rss.227
WAF網站配置問題
從其它相同配置的網站來看，WAF的配置并沒有什麼特别之處，即便跟其它正常網站的配置完全一緻，問題依舊存在。排查WAF的日志，基本把問題又指回了IIS 伺服器，因為日志明确的記錄了120s逾時的情況，
抓包分析
沖突點出現在WAF和IIS 伺服器之間，是以我們通過抓包來分析這兩個服務之間的互動情況。可惜，我們第一次抓包的結果無法解密，也就無法完全獲知WAF和IIS 伺服器的互動内容。為此，我們做了幾個嘗試，
- Windows上導出Certificate和Private Key為PFX，并設定密碼。配置在Wireshark的RSA Key中。
- Windows IIS 伺服器上 禁用Diffie-Hellman加密算法，并重新開機。
- 用戶端上配置SSLKEYLOGFILE="C:\temp\sslkey.log"，并在用戶端的Wireshark中指定。
具體方法網上都有，不一一列舉。最終，我們抓到了正常和異常的HTTPS資料流,通過解密後的資料包如下，
正常：用戶端直接連接配接IIS
異常：用戶端通過WAF連接配接IIS
很容易看到問題在于伺服器在一個SSL tunnel中給WAF 發送 HELLO REQUEST，但WAF沒有任何回複導緻IIS 一直等待在 RE-NEGOTIATE階段。而正常的情況下，用戶端能夠正确的處理這個請求，發送CLIENT HELLO。
Review TLS的RFC規範後，我們發現RFC中并未對用戶端接收到 HELLO REQUEST 的行為做明确的規定，
https://tools.ietf.org/html/rfc5246 在Windows Server 2008 R2的IIS實作中，IIS一直等待響應也未必是一個合适的行為。
解決方案
了解了問題發生的原因，HELLO REQUEST并不一定是必須的，具體我們通過IIS的幫助文檔，定位相應的配置Ignore避免了IIS發送HELLO REQUEST，