VPN software
07 January 2017Last month I wrote articles on the setting up of L2TP/IPSec servers and clients, but decided to keep them as focused guides rather than diving too much into commentary on politics and technology. In this article I present the excised material, as well as some follow-up information on using strongSwan directly rather than as a back-end for L2TP.
My first real experience with VPN setup was during my time in China, which was pretty much a case of use first thing I could get working rather than using the best software & protocols for the task. I initially tried out PPTP which was relatively easy to setup, but as far as I could tell PPTP support on Android is broken, and in any case PPTP has major security shortcomings. I eventually settled on L2TP/IPSec with PSK, although on Linux I used SOCKS over SSH tunnelling instead of VPNs, with actual VPN usage being limited to Windows and mobile (mainly Google Maps) use. Since getting back to Europe decided I ought to invest time in working out how to get ‘proper’ client-side VPN working on Linux.
Background & Motivation
To me the latest around of UK internet-related legislation was yet another piss-take in the name of public safety. In the past such laws were rammed through on the basis of ‘anti-terrorism’, which soon scope-crept to ‘serious & organised crime’, but in reality would mostly end up being used for international disputes and checking people's garbage disposal. You only have to look at the list of people who can get information without a warrant, which includes such delights as the Gambling Comission, Health & Safety Executive, HMRC, and even NHS Trust.In short if such information is stored, it will eventually be abused. It may be some government official trying to earn his bonus, or it may be a criminal looking for something to exploit, but either way it is merely a matter of time before someone looking for trouble goes snooping around. And the thing about people looking for trouble is that they tend to ‘find’ trouble even when it is not there. I'm not bothered by targeting from GCHQ or the NSA - what I do object to is guilty-until-proven-innocent trawling by people who from personal experience I know to be incompetent. People like HMRC who are unable to tell the difference between me and my father. And Bristol City Council who thought it would be a good idea to send a summons for unpaid council tax on a property they had previously given a refund due to it being sold.
Of course if government officials can trawl through something, then so will criminals. The only practical difference between the two is that the latter doesn't need to pay lip-service to anyone before doing so, and even that difference is looking doubtful. And things are not going to end here - the next port-of-call is going to be tightened censorship, of which UK authorities already have a history of bending to subjective influence. Both myself and friends of mine have spent significant amount of time in countries that have the sort of invasive censorship the UK is currently dreaming of, and in all cases it takes its toll on the quality of the internet connection.
Amount of privacy
If you are a serious terrorist, you should not be on the internet at all. Osama bin Laden survived for 10 years because he didn't even have a mobile phone, and way back in the 1970s the IRA used tricks such as leaving chalk-written messages on park benches to avoid British signals intelligence. Given government obsession with technology magic bullets, hiding in plain sight such as using Japanese on the back of a postcard is you best bet.For me stuff like Tor is overkill because I'm not after trace-proof anonymisation, so onion routing is not worth the overheads. Most websites I routinely access are ones that I have registrations for, and in any case widespread use of NAT proxies limits the usefulness of knowing a visitor's IP address. Most traffic analysis targets the browser rather than network connections, so avoiding that is the job of things like NoScript and Firefox's tracking protection.
Funnelling all personal traffic through a VPS does actually introduce a way in which your traffic patterns can be profiled, but the whole point is to put the required data beyond reach of specific entities rather than obliterate it completely. The purpose is to stop speculative snooping, not guard against a targeted attack. A VPN to personal VPS seems a good balance between anti-surveillance and effective network speed.
Terminology learning curve
One of the early difficulties with VPN is getting a grip on the terminology, which is not helped because of a tendency to refer to individual IPSec components as if they were distinct things. For instance “IPSec” normally means IPSec using IKEv1, whereas IPSec using IKEv2 is referred to as simply “IKEv2” without any mention of IPSec. Adding to the confusion, IPSec Hybrid RSA is IPSec Xauth RSA but without client-side certificates - to my knowledge the term hybrid comes from an exception to the rule in IKEv1: Userid/password pairs are normally only used to authenticate users, not the machines they are using.
The whole process involves finding out small bits of information on an ad-hoc basis, and quite often you realise that the way you did (and subsequently documented) something is actually not the best way. For instance it was only by chance that I found out how to avoid the need for putting entire Distinguished Names into leftid & rightid within ipsec.conf for certificate-based authentication.
Security considerations
A critical assumption behind all of this is is the benevolence of whoever is the VPS provider, and more importantly them being in a jurisdiction where detailed traffic logging (i.e. things like URIs rather than just a count of bits in & out) requires a proper prima facie process. Some VPS providers specifically dislike being used as a filtering proxy, but on the whole it is only really blatant abuse like spewing out emails for online pharmacies or launching DOS attacks that they are likely to take action against. If your VPS provider has been nobbled then whether or not they've been nosey around your VPS is a moot point as they can simply snoop the host machine's network ports.Server compromise
On the whole there is not very much that can be done to mitigate against a server break-in. The only such scenario that is not game over is someone getting a VPN connection but not a shell login, but then there is all the second-guessing which outbound ports will be useful to an attacker but not yourself. My inclination would be to limit outbound SMTP (and maybe IMAP & SSH) to servers I know I will be using, since bulk email has been the traditional use of partly-compromised systems. The only real mitigation against unauthorised VPN connections is to require traffic to be routed via proxies on the VPS, but that is self-defeating as the whole point in using a VPN is to avoid the need to reconfigure everything.Certificates vs. pre-shared keys
Although certificate-based security is in general better then pre-shared keys, most of the advantage is lost when there is already a secure channel available for settings up servers and clients. Even if low bit-density hexadecimal is assumed, it is still realistic for a high-quality (i.e. more than 80 bits of entropy) pre-shared key to be manually entered via a keyboard. In contrast a certificate/key has to be installed via a file transfer, which on Android devices has to take account of restrictive file access permissions. A pain when combined with getting the keys generated in the first place, and in single-user cases a system compromise is likely going to involve replacing most of the keys anyway.The one problem with pre-shared keys is that security is all-or-nothing, with the compromise of one server or client leading to the security of the whole setup collapsing. Not really an issue in single-user systems, but since the prevailing attitude seems to be that pre-shared key authentication is a deprecated mode of operation to be avoided, some VPN clients simply don't support them at all.
Technology overview
It did not feel like it at the time, but trying out various VPN protocols roughly corresponded with going through the history of them. What seems obvious in hindsight is revelation when it is something you've never really used before but need to get it up-and-running due to immediate requirements. And it is all the harder when information on VPNs themselves is blocked.PPPd
A protocol from the 1990s, PPTP is a back-end to PPPd, the big difference being the use of a network connection rather than a physical RS232 connection. L2TP uses the same architecture, with a virtual network interface appearing as the entrypoint of client VPN traffic into the server's networking subsystem. I'm not sure where encryption comes into the equation. Windows connected fine, in what was probably the only time I ever actually booted to Windows on my personal laptop in the last 6 months, but my Android mobile kept on dropping the connection. I eventually put this down to a buggy Android VPN client, but in hindsight there are so many security question-marks with the protocol it is just as well it did not work properly.SOCKS/SSH
Tunnelling is a standard part of SSH, and the ability of the SSH client to act as a SOCKS proxy removes the need to figure out which ports to forward. Setup effort is low, and anywhere you have an SSH login becomes a potential relay point. A few one-liner shell scripts and I can quickly change which of four countries to route my web browsing via. SOCKS over VPN is somewhat makeshift in feel, being best suited for ad-hoc on-the-road website viewing, but since about 95% of website usage is web browsing this is not a major issue in itself.The biggest downside of SOCKS over SSH is having to manually reconfigure programs to use it and this is where the 5% starts to become a pain. There are some wrappers such as TSOCKS that try to get around this, but they are a bit of a hack. I also suspect that SOCKS over SSH is not intended to tunnel as many open connections as some web browsers often have open, as there have been occasional problems with some websites.
L2TP/IPSec
L2TP/IPSec is something of a pain as it splits the whole process of VPN setup over multiple daemons, which also makes it too easy to accidentally use in an insecure manner, and on the whole I suspect it is a somewhat fragile setup. However for universal out-of-the-box use with many operating systems it seems to be the only real game in town. From what I have read IPSec Xauth/Hybrid is not supported out-of-the-box on Windows and I have come across hints about it having issues with some Android versions.Linux IPSec software seems to have gone through a bit of political instability, the end result being that strongSwan has become the preferred IPSec implementation. I've not been able to verify for myself, but it seems strongSwan is where most of the developers concerned with Linux IPSec ended up. A significant issue with strongSwan is that (rightly or wrongly) it seems to consider L2TP/IPSec a deprecated setup since it is notably absent from the configuration examples, and enabling it requires non-default parameters that all the older OpenSwan-orientated guides don't mention.
IKEv2 (native strongSwan)
For some reason I decided to have a look at the strongSwan Android VPN app, and one nice feature is that it allows certificates (but not user keys) to be imported directly, bypassing some of Android's irritations such as credential store security requirements. This was enough motivation to try out IKEv2 EAP (username/password) as an alternative to L2TP/IPSec with strongSwan, and it turned out surprisingly easy to get working. On the whole it seems much more stable with all the L2TP/PPPd stuff taken “in-house”, although doing away withppp0 network interfaces that PPPd used means it is less clear to me where packets enter & leave the kernel networking stack.