Windows Networking 6: about the standard something, WAF AND IIS SERVER HTTPS WORK exception problem-Alibaba Cloud Developer Community

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,

symptom

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.

Troubleshooting process

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,

network problems

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.

IIS server problems

by directly accessing the IIS server, we basically eliminate server handling problems. (The following is the access record of our test host)

curl -v https://hello.test.domain:8443/ -o /dev/null -s --trace-time --resolve hello.test.domain:8443:ip.add.rss.227

WAF website configuration

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,

packet capture analysis

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,

  1. export Windows and Certificate to PFX on the Private Key and set the password. The configuration is in the Wireshark of the RSA Key.
  2. Disable Windows IIS Diffie-Hellman encryption algorithm on the server and restart it.
  3. Configure SSLKEYLOGFILE = "C:\temp\sslkey.log" on the client and specify it in the Wireshark of the client.

Specific methods are available online, not listed one by one. Finally, we caught normal and abnormal HTTPS data streams. The data packets after decryption are as follows,

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,

https://tools.ietf.org/html/rfc5246

in the IIS implementation of Windows Server 2008 R2, it may not be appropriate for IIS to wait for a response.

Solution

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,

Selected, One-Stop Store for Enterprise Applications
Support various scenarios to meet companies' needs at different stages of development

Start Building Today with a Free Trial to 50+ Products

Learn and experience the power of Alibaba Cloud.

Sign Up Now