Web Proxy And The Need For SSL Decryption

Most organizations will deploy a Web Proxy solution, but not intercept HTTPS traffic to do SSL decryption and inspection. This may be done for various reasons

* Not yet having a PKI infrastructure to manage the SSL browser certificates
* Perhaps the AD/GPO team doesn’t want to manage SSL certificate on the user PC
* Security teams may be weary about man-in-the-middle issues
* Maybe SSL interception just wasn’t a concern at the time.

Without doing SSL decryption and inspection our ability to filter or perform an action on HTTPS  traffic is tricky unless the destination IP is known and added to a DENY rule on the proxy. The problem with doing this, is that it even if you are good enough to find the specific IP that is being misused over HTTPS, it is impossible to see what is going on inside the tunnel without SSL decryption and inspection, so you are just guessing on what is actually happening. It’s not a very exact science, and takes much more time that its worth to fight the issue.

When an internet proxy is not intercepting HTTPS traffic and doing SSL decryption and inspection, the HTTPS protocol is at risk of being exploited and used to bypass security policies. Most organizations place their internet proxy just inside of a perimeter or egress firewall and allow the proxy to access the internet on ports 80 and 443. This rule basically states that anyone making an web connection to the internet through a proxy is allowed to any destination on either HTTP or HTTPS, except where denied by proxy policy of course.

The problems arise due to applications that connect to the internet are now able to be configured to use the port of your choosing. The proxy is not set up by default to delve into connections, meaning it does not analyze the allowed protocols that might be getting used as a simple tunnel to harbor another application. The best example I’ve found is to set up an external SSH server that is modified to listen on TCP 443 instead of TCP 22. This setup allows a connection to pass both the proxy and the firewall, undetected, on its way to the external SSH server now listening on our wide open TCP 443. Both the proxy and the firewall, by default, see a TCP 443 connection and allow it based on policy.

This is difficult to detect if you are not looking for it specifically. Now, if you are the proxy administrator or engineer responsible for the device, you most likely have access to the reporting tools and can find information in the logs to support your case. If you suspect it is happening, and you look in the logs, you will need to look for connections to public IP addresses with a category of “TCP Tunnel”. Further investigation of the destination IP addresses my be of some help, or you can keep looking into reporter for the source address and track it back to the specific computer/user-id that the traffic is originating from.

It may not always be something that is being done by the employee in an attempt to bypass the internal web security policy, but rather a program that is trying to “phone-home”, as part of an APT (advanced persistent threat) malware program, etc…