How to identify if you are behind a "Transparent Proxy"

Published: 2012-12-06
Last Updated: 2012-12-06 03:25:35 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

Traveling a lot? You may still be one of the unlucky few who not only connects to hotel networks regulary, but doesn't have easy access to a VPN to bypass all the nastyness they introduce. In addition, even some "normal" ISPs do introduce a feature called "transparent proxy" to manage traffic. Transparent proxies are nice in that they are easy to setup up and invisible ("transparent") to the user. However, the browser isn't aware of them, and as a result the transparent proxy even if configured non-malicious can still cause confusion bout the same origin policy browser depend on to isolate web sites from each other.

A transperent proxy works in conjunction with a firewall. The firewall will route traffic to the proxy, but changing the desitination IP address of the packet to the proxy's IP address. The proxy now relies on the "Host" header to identify the target site. As a result, the relationship between IP address and host name that the client established is lost.

There is a pretty simple test to figure out if you are behind a simple transparent proxy: Telnet to a "random" IP address (e.g. 192.0.2.1) on port 80. Then, copy/past a simple HTTP request, that includes the host header (the part you type is shown in bold font:

telnet 192.0.2.1 80
Trying 192.0.2.1...
Connected to 192.0.2.1 (192.0.2.1).
Escape character is '^]'.
GET /infocon.txt HTTP/1.1
Host: isc.sans.edu
 
If this works, and you are connected to "isc.sans.edu" and not "192.0.2.1" (which doesn't exist), then you are behind a proxy. The response may now also include headers inserted by the proxy. For example (abbreviated):
 
HTTP/1.1 200 OK
Date: Thu, 06 Dec 2012 03:05:12 GMT
Content-Length: 5
...
Content-Type: text/plain; charset=UTF-8
Via: 1.0 localhost:3128 (squid/2.7.STABLE9) <--- PROXY HEADER
 
 
And other similar headers. (X-Cache-Lookup, X-Cache ...)
 
If https connections are proxied, you will also see SSL warnings. Disconnect if you see them. Using an "open" internet connection without a VPN to tunnel you back to the safety of the known-evil home ISP is your best choice. There are plenty of decent options. Some home routers now include either OpenVPN or IPsec gateways. Personally, I like OpenVPN, but for mobile devices, IPsec is more common. You may need both anyway as some special-evil networks block VPN connections. OpenVPN for example can even work by encapsulating your TCP/IP traffic in HTTP requests that will be passed along by an evil transparent proxy. Setting up a PPP connection over SSH is another option, but it is less supported by non-linux clients. Of course, you should still use SSL to connect to critical services to get an end-to-end authenticated and encrypted tunnel.
 
------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: hotel ipsec openvpn proxy transparent proxy vpn
6 comment(s)
Join us at SANS! Attend Application Security: Securing Web Apps, APIs, and Microservices with Johannes Ullrich in San Francisco starting Dec 05 2022

Comments

When behind an SSL inspection proxy, you may be tempted to install the CA certificate that comes with such devices, used to generate spoofed certificates on-the-fly. If you do, make sure the certificate isn't compromised (i.e. the associated private key has been published).

Importing a compromised CA certificate in your web browser and/or OS (or Java environment etc.) completely breaks PKI (including binary- and e-mail signature verification) on your PC.

For example, Cyberoam devices:
https://blog.torproject.org/blog/security-vulnerability-found-cyberoam-dpi-devices-cve-2012-3372

Fortinet Fortigate devices:
http://www.kb.cert.org/vuls/id/111708

These are examples; other SSL inspection devices are known or suspected to come with default (identical) CA certificates (plus private keys) in firmware which, IMO, means that you should treat them as compromised (the solution is that administrators of such devices replace the CA certificate by a self-signed cert they generated themselves, in a secure manner - which is far from obvious).

Erik van Straten

Dec 6th 2012
9 years ago

It's worth noting that not all transparent proxies translate the Host header to make their connection. Some simply connect to the intended destination IP. So having this test fail is not necessarily a sign that you're *not* behind a proxy.

Will

Dec 6th 2012
9 years ago

There are even proxies that are able to spoof the clients IP so
they are transparent towards the server side too.

An interesting test is to use tcptraceroute from the client.
You would see the internet webservers always at the same hop
behind the router where the proxy lives.

Jens

Dec 6th 2012
9 years ago

I've found these tools are useful for identifying proxies:

http://www.lagado.com/proxy-test
http://www.lagado.com/tools/cache-test

Chuck

Dec 7th 2012
9 years ago

Question, it is my general understanding that if you use SSL/HTTPS that even with a transparent proxy they can not see into the stream since the certificate is owned by the website and checked for validity. Am I working on an invalid assumption? And if so is this always invalid or is it limited to certain circumstances?

BGC

Dec 7th 2012
9 years ago

@BGC - it depends. If you are on my employer's network, there is a mandatory MitM decryption done at our proxy and re-encrpytion using our own CA cert (which we have AD GPOs add to all our workstations). Without that, you would get CA trust issue errors, but if you ignored that your traffic would still flow, and our proxy would analyze it all for threats (inbound) and data protection (outbound).

We do have a list of whitelist exclusions which we do not perform this for (banking, HR functions such as healthcare, etc.). Additionally we have to whitelist a handful of places that require client certificates and are business essential.

Additionally, if one does not do this, or does not have a whitelist-only proxy, and if you don't have 802.1x LAN auth and total workstation lockdown (no external media, etc.), there is nothing to stop someone from running an SSL VPN or SSH over port 443 with an http-proxy add-on liie corkscrew, and naturally the proxy will just blindly forward on the 443 traffic.

Jason R

Dec 7th 2012
9 years ago

Login here to join the discussion.


Top of page
Diary Archives