Inflation, Investing and Everything
From time to time, somebody, maybe a friend, or FOAF (friend-of-a-friend) might ask me about accessing some Internet service from behind a firewall. Most likely it'll be a corporate firewall, or perhaps it may be one that's installed at some educational institution.
Most of the time, I will tell them something like, "this is one of the Dark Arts of Networking - it's not easy, it might not work, and it might be frowned upon." Furthermore, it's a good chance they're not uber-geeks and have no idea of the "issues involved".
One of the best articles out there regarding this topic has a rather catchy title (for uber-geeks, that is) : "Punching holes into firewalls". Alternatively, the author has titled it "Why firewalls shouldn't be considered a ultimate weapon for network security" and "Secure TCP-into-HTTP tunnelling guide".
The basic idea is to create a tunnel through a HTTP proxy in which you can stuff TCP packets from your machine behind the firewall to some other server out there - most likely that will be your home PC connected to your broadband cable or ADSL modem, or perhaps if you're more lucky, you have access to a server sitting on a high-bandwidth network that you can use (I did say it is geek territory, didn't I).
The possible issues :
1. HTTP proxy servers weren't meant to transfer generic TCP traffic reliably. The HTTP protocol is meant to serve up web pages to you. You may encounter latency issues, timeouts, and buffering problems.
2. You need a web server that the HTTP proxy server can reach. That means probably a Tomcat or something similar. You don't want to use the default ports, which might be probed, say, ten thousand times a day by hackers, script kiddies, your ISP, the CIA, FBI, or some other agency.
3. You need special server software sitting on this web server that is able to unwrap incoming TCP traffic, re-direct it, and send the return traffic back over the HTTP tunnel. It must have its own special, non-standard protocol.
4. You also need client software that speaks the same protocol. Preferably, it uses the basic HTTP GET or POST commands. Some of the tunnelling software packages out there rely on CONNECT, which isn't so good because some firewalls/proxy servers have the CONNECT command disabled, while others enable it only on the default SSL port 443 (which you also should avoid, due to the probe issue mentioned in #2).
5. For the paranoid (like myself), the TCP traffic had better not be sent in cleartext. Some kind of encryption has to be utilised. Preferably strong encryption, with "lots of bits" (128, 256, etc). What's the point of exerting great effort trying to set up a covert channel with a complicated protocol that works over HTTP proxies if all it takes is a sniffer or packet dump that can uncover everything you're sending? For that, you need the services of something like OpenSSH or Zebedee, but that means yet another layer of complexity. Alternatively, you can use HTTPS and leave it to TLS/SSL to take care of the encryption part.
For the latest practice in "the dark arts of networking", let's say we use the following :
2. A copy of the SOHT (Socket over HTTP Tunneling) client and server. It's a Java open-source project.
3. My patch to SOHT to support HTTPS. SOHT has got a nice protocol but the patch is necessary to a. make HTTPS work, b. ignore certification path errors, c. ignore hostname verification mismatch errors.
Once you have all that, all you need is to set up the port mapping and you're done. Then you can FTP (passively), SCP, SSH, POP, or SMTP all you want.
And if you want to surf securely, (anonymously, secretly, etc.) try installing the Anomic/Yacy HTTP proxy server.
Most popular blog postings on lowem.log :
1. Singapore MRT rail network length to double by 2020
Featured articles on lowem.log :
1. Book review : Shut Down by William Flynn