Internal proxies are fine. How do you get to Google if not through port 80? I mean, why would you even have a web browser installed
at all if outgoing connections to port 80 were blocked?
I have a dynamic DNS setup for my LAN at home, so that I can get to everything on it while I'm out. Right now, my firewall just forwards port 80 to my OpenBSD server (Apache), so it's only serving standard HTTP. But I can easily ssh to it (since port 22 is also forwarded to the OpenBSD server) and change the Apache configuration to listen for HTTPS on port 80. With this kind of service in place, I can get to any website in the world, including blacklisted sites; torrent sites, porn sites, whatever... through an internal [corporate, educational, private] proxy.
Let's say I'm at your school, and they have this setup with Firefox connecting to their internal proxy (which does *all kinds* of wonderful content-level filtering, by the way ... blocking evey site that ever mentions keywords like "torrent" or "porn"). My dynamic DNS service is actually kodewerx.pwnz.org, and if I had the HTTPS-over-port-80 setup (as explained above, I don't) then I would only have to connect to
https://kodewerx.pwnz.org:80/ and I would foil the content-level filtering of that internal proxy. (This also assumes I'm running a CGI/PHP [web-based] proxy on my server, which I am not.)
Why? Well, for one, proxy admins like to limit or completely disable HTTPS connections, because they are impossible to reliably snoop on. Just connecting to kodewerx.pwnz.org over port 443 (HTTPS) might be a red-flag, and they could blacklist all connections to that IP. HTTPS-over-port-80 is very unusual, though. Port 80 carries (in nearly all cases) an unencrypted HTTP session. To have an HTTPS session tunneled through port 80 means that that internal content-filtering proxy is only ever going to see a scrambled mess of data, instead of any content that ends up at your browser.
It doesn't stop there, though! Unless that proxy is also acting as your *only available* DNS server, chances are that the proxy will never actually know that your connection is going to a domain called "kodewerx.pwnz.org" anyway. It will only know that you are reaching an "HTTP" service hosted on a private IP address; and that IP address
cannot be reverse-looked up to "kodewerx.pwnz.org". This is the real beauty of dynamic DNS; not only can I create as many of these as I want (endless numbers of subdomains on countless domains), but I can be assured that my real IP, when looked up, will never resolve back to any of those domains.
And when my IP is blacklisted? I whip out my iPhone, connect to it over the cellular network, force it change my IP (it is dynamic, after all, why not have a script to actually *request* it to change?) and 5 seconds later, "kodewerx.pwnz.org" (and all my other dynamic DNS domains) point to a different IP. Ad infinitum.
The only thing that can stop this is:
- an IP whitelist (which breaks the entire internet -- so you're unlikely to encounter this situation if you can reach *any* common website like Google)
- a blacklist over your ISP's entire IP range (ouch! well you do have shell accounts elsewhere, right? I do, lol)
- a *really* smart filtering proxy that knows exactly what is being sent over port 80, and can naturally adapt to it. (I would be personally impressed if any IT outfit has a configuration like this in place that actually works -- in all cases.)
I reiterate my previous statement: That's interesting, considering it's pretty much impossible [to keep you from reaching the websites you wish].