The Security Funnel: When OpenVPN Meets Tor
by Wananapaoa Uncle
#include <std-disclaimer.h> #include <do-it-at-your-own-risk.h> #include <play-fair.h>About
We want privacy.
We really care about it, and that's why we protect our data with encryption by using PGP, SSL, and VPNs. We trust our encryption schemes, so we are pretty comfortable with them, especially while using open-source software. But sometimes we don't care enough about the fact that even if the conversation or data flow is garbled, the two parties are known to the eavesdroppers.
This is what we are talking about here.
Meet OpenVPN
I'm not going to explain here the details of OpenVPN. There are dozens of well-written references on the net, so I'll concentrate on the concepts.
OpenVPN is open-source software that lets you establish secure VPN tunnels between two endpoints or two networks. Not very new as a concept itself, but OpenVPN has several advantages for security conscious users, primarily one: you can spelunk the source code.
In real-world, most people won't, but lots of people have done it and it seems to be a pretty safe software. Also, it is thought to use certificate-based authentication of both parties, although it can use other methods.
Another big advantage of OpenVPN is its simple networking requirements: it just needs a port from the client to the server, be it a TCP or UDP one, and, even better, the port can be forwarded through several layers of NAT without problems.
Lots of open-source firewalls integrate OpenVPN servers and client for a simplified setup. Basically, you can reach your home network from any connected spot in the world, and be confident your traffic is safe. Another big feature of OpenVPN is that it is run on all of the major computing platforms around.
Meet Tor
Tor is open-source software used to create a network over another one, for example the Internet.
It is not a VPN mechanism because it aims at obtaining another goal: creating a path from a client to the server, where neither knows the IP address of the other. Moreover, no one on the Internet can have complete visibility over the two parties of the communication; the client connects to an "entry node" and the communication to the final host is performed by an "exit node."
The path between is handled by several hosts that cryptographically "see" only their adjacent neighbors.
Matching It All Up
So, after these very brief introductions, we can state that OpenVPN is aimed at secure communications and Tor towards anonymity.
What we want to do is mix up the things and be able to connect to our OpenVPN servers through Tor, for example, when we are (uninvited) guests of some guy's network who could have sniffers plugged in somewhere.
We need some technical insights on the workings of Tor.
It is based on a technique called "onion routing" that is necessary to achieve anonymity, but also disrupts the normal way IP packets are routed since routing information is stored in upper (cryptographically secured) protocol layers. So to gain access to the Tor network, you need special software.
This comes in the form of the Tor executable/daemon that on one side connects to the Tor network, and on your side presents itself as a SOCKS proxy. SOCKS proxies existed long before Tor and implement a generic method to relay network connections.
The good news is that differently from, say, HTTP proxy, SOCKS ones are generic enough to let you pass Level 4 protocols without knowledge about upper level ones.
For example, you need a specialized HTTP proxy to support HTTP/1.1 specifications, but SOCKS proxy can relay SSH v1-2-whatever as well as FTP, for example.
The bad news is that to make use of SOCKS proxies, each client application must specifically support it: your web browser, SSH client, FTP client, and so on need to have some form of "SOCKS proxy configuration," be it a dialog box or a setting in the configuration file/command line.
There is also another option: using transparent gateways (like TorBOX, for example).
They have some nice points and some negative ones. The biggest negative I found is that they hide some important things you must know for your security. And we do want to know how stuff works, so refer to trac.torproject.org/projects/tor/wiki/doc/TorBOX if you're interested.
Back to good news.
Our good friend OpenVPN does support SOCKS proxy and, at the time of this writing, version 2.2 supports version 5 SOCKS in a stable manner.
If you read the OpenVPN documentation (which I hope you do), you know that probably there are advantages in using the UDP protocol as transport. Again, the bad news is that Tor only supports TCP connections. To be honest, Tor also adds some performance penalty to the whole thing, so you probably won't notice any difference in using TCP for OpenVPN.
Now, to make a long story short, to set it all up:
1.) You must create an OpenVPN server configuration file using the TCP protocol option.
2.) Create the appropriate client configuration file using TCP-client protocol. Test that it works the direct way.
3.) Set up Tor to run. This can be on your local machine or on a remote host, preferably on your LAN. If you used the defaults, you'll have it listen on loopback address (127.0.0.1) and port 9050 (TCP of course).
4.) Go back to your OpenVPN client. You can modify the configuration file or launch the executable using parameters, so:
If running on Windows, the easiest way is to use the OpenVPN GUI icon in your tray bar (it is installed by the package you download). Right-click it, select "Proxy Settings," then "Manual Configuration" and tick "SOCKS Proxy." Enter 127.0.0.1 for the address and 9050 for the port, or the address and port of your Tor proxy if not installed on the local host.
If running some sort of UNIX, just add --SOCKS-proxy 127.0.0.1 9050 to your command line.
On any platform, adding SOCKS-proxy 127.0.0.1 9050 to the config file will persist the setting.
Starting the connection will spit you the confirmation that you're going through the proxy, hence via the Tor network:
Plan B
There's another Tor feature that can be handy: hidden services.
If you need to publish a generic service, say SSH or web, you can configure your Tor client to expose them, just by indicating the listening port and the destination host:port, like any home firewall. There are a couple of interesting differences:
Tor gives your service a special name, which is reachable only from the Tor network. This is not per se, a security feature, as anyone on the Tor network can connect to it, but lessens the extent of probes to your service that come from the Internet by drone port scanners. If you ever had SSH on a standard port, you'll find your logs filled with fake root login attempts.
It works behind NAT and dynamic IPs, since it is the Tor client that performs an outgoing TCP connection to the Tor network.
So, having the Tor client running on a machine on your network (not necessarily the one where you run OpenVPN), you can just add these two lines to your torrc file:
We have /var/torhsvcs/hs0 (on Windows you can use something like C:\TORSVC\HS0) being the directory in which Tor will create two files: one containing the private key for your service (you must keep it safe!) and one "hostname" containing one line with the Tor pseudo name of your service, just like: 58ewjwefj6ka030.onion
This will be the name of your service to put into the OpenVPN client "remote" line.
You must have a different directory for each hidden service.
Please read carefully considerations about DNS and torified services in the Tor docs, as name resolution alone can disrupt your privacy.
With those two lines, after you start Tor, it will listen (see second line) on port 3000 for a Tor connection to that strange .onion name, and redirect all traffic to 127.0.0.1 port 2000, where you presumably made OpenVPN listen.
Again, you can use 192.168.3.7:2500 to redirect traffic to an internal machine on your network having OpenVPN listen on port 2500 of host 192.168.3.7.
The advantage of using hidden services in this setup is that you did not expose the OpenVPN service to the Internet, but only to the Tor network.
The disadvantage is that your client always needs to be connected to the Tor network to perform a connection, so even when you are connected to legitimate networks, you cannot directly set up an OpenVPN. It's up to you. Normally, Tor hidden services are configured so that neither the client nor the server know each other's IP. That, in our case, may be a plus or a minus.
Conclusions
Both OpenVPN and Tor are sophisticated tools.
Their sites (www.openvpn.net and www.torproject.org) contain lots of configuration examples and, especially for Tor, a lot of caveats you must understand in order for your privacy to be respected.
Please read them carefully.
After reading, understanding, and setting up the whole thing, you may benefit both from secure and anonymous access to your network, even when you're "leasing" an untrusted connection.