IIS Web Service is also a mainstream HTTP Service software. Many MS applications run on IIS, and some users use the platform provided by IIS to run their. Net Framework applications. For website security, many users choose to put a layer of WAF in front of the IIS server to avoid attacks. This time, one of our users encountered an interesting problem,
IIS Web service, many website applications are run on it, which are distinguished by SNI. Place a layer of WAF back-to-origin before the IIS server. The user reported that a IIS Web site failed to return to the origin through WAF.
The main phenomenon is that when visiting the website, the browser has been loading, returning error codes such as 502/504, accompanied by 499 errors.
because IIS Web service is basically a black box for us, and there are basically no error logs and access logs when problems occur, we basically adopt the scheme of bold speculation and careful verification to locate the problem step by step. As a whole system, the problem is nothing more than these aspects,
we have tested the connectivity of all the IP addresses involved and their corresponding ports. telnet and tcpping show that the connection three-way handshake is normal.
curl -v https://hello.test.domain:8443/ -o /dev/null -s --trace-time --resolve hello.test.domain:8443:ip.add.rss.227
in terms of other websites with the same configuration, the WAF configuration is nothing special. Even if the configuration is exactly the same as that of other normal websites, the problem still exists. After troubleshooting the WAF log, the problem is basically pointed back to the IIS server, because the log clearly records the 120s timeout,
conflicts occur between WAF and IIS servers. Therefore, we analyze the interaction between the two services by capturing packets. Unfortunately, the first packet capture result cannot be decrypted, and the interaction content between WAF and IIS servers cannot be fully known. To this end, we made several attempts,
- export Windows and Certificate to PFX on the Private Key and set the password. The configuration is in the Wireshark of the RSA Key.
- Disable Windows IIS Diffie-Hellman encryption algorithm on the server and restart it.
- Configure SSLKEYLOGFILE = "C:\temp\sslkey.log" on the client and specify it in the Wireshark of the client.
normal: The client directly connects to IIS
exception: the client connects to IIS through WAF.
It is easy to see that the server sends SSL tunnel to WAF in a HELLO REQUEST, but WAF does not reply, causing IIS to wait for the RE-NEGOTIATE phase. Normally, the CLIENT can correctly process the request and send CLIENT HELLO.
After Review TLS RFC specifications, we found that the RFC does not specify the behavior of clients receiving HELLO REQUEST,
in the IIS implementation of Windows Server 2008 R2, it may not be appropriate for IIS to wait for a response.
after understanding the cause of the problem, HELLO REQUEST is not necessarily necessary. For more information, we can locate the corresponding configuration Ignore through the IIS Help document to avoid IIS sending HELLO REQUEST,