I was monitoring some events from our web application firewall (WAF), Imperva SecureSphere, when a weird one appeared. Here is the client's POST request:

POST some_url   HTTP/1.1
Host: client_url 
Content-Type: application/x-www-form-urlencoded 
Origin: https://client_url
Accept-Encoding: gzip, deflate 
Cookie: Some_cookie
Connection: keep-alive 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Version/10.0 Mobile/14D27 Safari/602.1 
Referer: https://referer_url
Content-Length: 110 
Accept-Language: ja-jp 
X-Forwarded-For: some_ip_address 

loginPasswd=plain_text_passwd <- wait, WHAT!

I'm not an expert at the application level security, but plain text password in a POST request doesn't smell good. Since the WAF acts as a proxy, my client seems to be vulnerable to a MitM attack.

Here is my question

How come the POST information part wasn't encrypted? TLS seems to be used:

loginPasswd=plain_text_passwd <- wait, WHAT!
  • 4
    TLS does not selectively encrypt data, it encrypts the channel ... If you expected TLS, then you should not have been able to read the data at all
    – schroeder
    May 30, 2017 at 9:24
  • 5
    Where do you read that data? The X-CUSTOMER_NAME-PROTOCOL: https let me think that you got it after a reverse proxy that has processed the TLS decryption. If it is the case, all is normal... May 30, 2017 at 10:12
  • 1
    Thanks @schroeder and Serge ,i get it now. The data were decrypted before processed by the WAF. That make sense.
    – Emka
    May 30, 2017 at 10:25

1 Answer 1



You're probably seeing plaintext information in the event logs because the WAF decrypts the data as part of its analysis.

How come the POST information part wasn't encrypted, since TLS seems to be used

To be sure we'd need more information about your network setup, but I'll take a guess (as in Serge Ballesta's comment):

The information was encrypted (by the client browser), but it was decrypted by some appliance to better analyse it.

Web application firewalls usually have the ability to not only intercept HTTPS traffic, but to decrypt it, because otherwise they could not meaningfully analyse the traffic. This is called HTTPS inspection. Incidentally, the Imperva WAF (called Imperva SecureSphere Web Application Firewall) happens to offer HTTPS inspection, so most likely it decrypted the traffic itself.

Note that HTTPS inspection is a powerful, but dangerous tool, because it breaks the end-to-end nature of HTTPS, so it should be deployed with care. But that decisions seems to have been taken already in your case...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .