Skip to content
 

Poor man’s HTTP VPN

There is a program floating on the net called httptunnel which is essentially a tool to forward arbitrary TCP connections over HTTP, similar for example to SSH's port forwarding capabilities (except, of course, that SSH carries the data over the SSH channel, while httptunnel puts the data into what appears to be "normal" HTTP traffic).
Now such a tool has a great potential, and as usual, it can be used for many purposes, both legitimate and questionable. So before going further, let me fully quote the contents of the file DISCLAIMER that comes with httptunnel:

I hereby disclaim all responsibility for this hack. If it backfires on
you in any way whatsoever, that's the breaks. Not my fault. If you
don't understand the risks inherent in doing this, don't do it. If you
use this hack and it allows vicious vandals to break into your
company's computers and costs you your job and your company millions
of dollars, well that's just tough nuggies. Don't come crying to me.

What we will do here is create a full fledged VPN over HTTP using httptunnel, which means that the potential is even greater, and the above disclaimer holds even more. Let me state it again: you are the sole responsible for your actions. Keep this well in mind.

The way httptunnel works is in a client-server fashion: the server (the hts program) listens on an arbitrary TCP port (8888 by default) and when a connection comes in from the client part, it forwards it to an arbitrary host and port (specified on the command line). For example:

server # hts -F 127.0.0.1:110 12345    # listen on port 12345 and forward to port 22 on local host

The client part (the htc program) opens a port on the host on which it runs, and also connects to the server where hts is running. For example:

client # htc -F 11223 192.168.4.18:12345    # listen on port 11223 and connect to server at 192.168.4.18, port 12345

The result of the above example configuration is that if you connect to port 11223 on the client, the connection is forwarded to port 110 on the server over an HTTP channel which runs from the client to the server's port 12345.

(for those familiar with SSH's port forwarding, the result is simlar to running

ssh -L11223:127.0.0.1:110 user@192.168.4.18

on the client machine except, as said, that SSH uses SSH - ie, a TCP connection to the server's port 22 by default - to carry the data).

No need to mention that hts server could be run on a different and, um, more "friendly" port, and the htc client supports some extra options, among which the use of an HTTP proxy (read the help or man pages).

Now how do we exploit httptunnel to carry raw IP traffic? This is where the mighty socat comes in. IP traffic and VPN, in Linux, almost invariably means a tun/tap interface, which socat supports. Additionally, we note that both hts and htc support reading and writing from/to stdin/stdout (instead of a TCP port), with the -s option. Putting it all together, here's what we run on the server:

server # socat 'EXEC:hts -s' 'TUN:10.0.0.1/24,iff-up'

After this, socat runs hts (which listens on port 8888 by default) and connects hts's stdin and stdout to the tun interface. On the client, we run

client # socat 'EXEC:htc -s 192.168.4.18' 'TUN:10.0.0.2/24,iff-up'

where 192.168.4.18 is the address of the machine running socat+hts. To run the server on a different port, or use other options (both on the server and the client), modify the hts/htc command lines in socat's EXEC part accordingly.

After this is done, verify that traffic can be sent between 10.0.0.1 and 10.0.0.2, and the (pseudo) VPN link is ready. With appropriate setup (routes on the client, forwarding/NAT etc. on the server), the client can direct part or all of its IP traffic over the httptunnel link.

CAVEATS: this is a "kind of" VPN, traffic obviously is NOT encrypted. Also, httptunnel has NO authentication mechanisms, so if somebody discovered your listening hts, they could run socat+htc on their machine and send traffic through and (more worryingly) TO your server when you're not using it. Finally, in many networks there are restrictions that are not meant to be circumvented; make sure that whatever you do, you are allowed to do it. Let's repeat it one more time: YOU ARE RESPONSIBLE. Think carefully. Be reasonable.