With Edward Snowden’s shocking revelations that the NSA has for years been working to crack and subvert VPN encryption technologies, together with the fact that it is becoming increasingly obvious that most such technologies have been developed and certified by the US government’s National Institute of Standards and Technology (NIST), may therefore be considered suspect.
This article will start with a rundown of the major differences between the different VPN protocols and how they affect you, followed with looking at detailed key concepts involved in cryptography, and how the NSA’s assault on encryption standards affects the different VPN methods.
VPN setup and management have typically been the responsibility of Network Engineers but from my experience in multiple industries, companies try to cut more and more costs and increase value by routinely forcing existing Systems Administrators to absorb the VPN configuration tasks. VPN’s are becoming more and more complex due to the obvious function of a VPN.
The discussion below is rather technical, and you may prefer to just jump to the end of the article for a quick summary.
Point-to-Point Tunneling Protocol was developed by a consortium founded by Microsoft for creating VPN over dialup networks, and as such has long been the standard protocol for internal business VPN. It is a VPN protocol only, and relies on various authentication methods to provide security (with MS-CHAP v2 being the most common). Available as standard on just about every VPN capable platform and device, and thus being easy to set up without the need to install additional software, it remains a popular choice both for businesses and VPN providers. It also has the advantage of requiring a low computational overhead to implement (i.e. it’s quick).
However, although now usually only found using 128-bit encryption keys, in the years since it was first bundled with Windows 95 OSR2 back in 1999, a number of security vulnerabilities have come to light, the most serious of which is the possibility of unencapsulated MS-CHAP v2 Authentication. Using this exploit, PPTP has been cracked within 2 days, and although Microsoft has patched the flaw (through the use of PEAP authentication), it has itself issued a recommendation that VPN users should use L2TP/IPsec or SSTP instead.
Knowing that PPTP was insecure anyway, it came as no surprise to anybody that the NSA almost certainly decrypts PPTP encrypted communications as standard. Perhaps more worrying is that the NSA has (or is in the process of) almost certainly decrypted the vast amounts of older data it has stored, which was encrypted back when even security experts considered PPTP to be secure.
|– Client built-in to just about all platforms
– Very easy to set up
|– Not at all secure (the vulnerable MS CHAPv2 authentication is still the most common in use)
– Definitely compromised by the NSA
L2TP and L2TP/IPsec
Layer 2 Tunnel Protocol is a VPN protocol that on its own does not provide any encryption or confidentiality to traffic that passes through it. For this reason it is usually implemented with the IPsec encryption suite (similar to a cipher, as discussed below) to provide security and privacy.
L2TP/IPsec is built-in to all modern operating systems and VPN capable devices, and is just as easy and quick to set up as PPTP (in fact it usually uses the same client). Problems can arise however, because the L2TP protocol uses UDP port 500, which is more easily blocked by NAT firewalls, and may therefore require advanced configuration (port forwarding) when used behind a firewall (this is unlike SSL which can use TCP port 443 to make it indistinguishable from normal HTTPS traffic).
IPsec encryption has no major known vulnerabilities, and if properly implemented may still be secure. However, Edward Snowden’s revelations have strongly hinted at the standard being compromised by the NSA, and as John Gilmore (security specialist and founding member of the Electronic Frontier Foundation) explains inthis post, it is likely that it has been been deliberately weakened during its design phase.
L2TP/IPsec encapsulates data twice which slows things down, but this is offset by the fact that encryption/decryption occurs in the kernel and L2TP/IPsec allows multi-threading (which OpenVPN does not.) The result is that L2TP/IPsec is theoretically faster than OpenVPN.
OpenVPN is a fairly new open source technology that uses the OpenSSL library and SSLv3/TLSv1 protocols, along with an amalgam of other technologies, to provide a strong and reliable VPN solution. One of its major strengths is that it is highly configurable, and although it runs best on a UDP port, it can be set to run on any port, including TCP port 443. This makes traffic on it impossible to tell apart from traffic using standard HTTPS over SSL (as used by for example Gmail), and it is therefore extremely difficult to block.
Another advantage of OpenVPN is that the OpenSSL library used to provide encryption supports a number of cryptographic algorithms (e.g. AES, Blowfish, 3DES, CAST-128, Camellia and more), although VPN providers almost exclusively use either AES or Blowfish. 128-bit Blowfish is the default cipher built into OpenVPN, and although generally considered secure, it does have known weaknesses, and even its creator was quoted in 2007 as saying ‘at this point, though, I’m amazed it’s still being used. If people ask, I recommend Twofish instead’.
AES is the newer technology, has no known weaknesses, and thanks to its adoption by the US government for use in protecting ‘secure’ data, is generally considered the ‘gold standard’ when it comes to encryption. The fact that it has a 128-bit block size rather than Blowfish’s 64-bit block size also means that it can handle larger (over 1 GB) files better than Blowfish. However, both ciphers are NIST certified, which while not widely recognized as problem, we have issues with. See below for a discussion about this.
How fast OpenVPN performs depends on the level of encryption employed, although technically speaking IPSec is faster than OpenVPN because encryption/decryption is performed in the kernel, and because it allows for multi-threading, which OpenVPN does not.
OpenVPN has become the default VPN connection type, and while natively supported by no platform, is widely supported on most through third party software (including both iOS and Android).
Compared to PPTP and L2TP/IPsec, OpenVPN can be a bit fiddly to set up (although this is a very very subjective judgement.) When using generic OpenVPN software in particular (such as the standard open source OpenVPN client for Windows), it is necessary to not only download and install the client, but also to download and setup additional configuration files. Many VPN providers get around this configuration problem by supplying customized VPN clients.
Perhaps most importantly in light of the information obtained from Edward Snowden, it seems that as long as Perfect Forward Secrecy (ephemeral key exchanges, which we discuss later) is used, then OpenVPN has not been compromised or weakened by the NSA.
Although no-one knows the full capabilities of the NSA for sure, both the evidence and the mathematics strongly point to OpenVPN, if used in conjunction with a strong cipher and ephemeral keys, being the only VPN protocol that can be considered truly secure. Unfortunately, not all VPN providers use PFS when implementing OpenVPN…
Secure Socket Tunneling Protocol (SSTP) is a form of VPN tunnel that provides a mechanism to transport PPP traffic through an SSL/TLS channel. SSL/TLS provides transport-level security with key-negotiation, encryption and traffic integrity checking. The use of SSL/TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers except for authenticated web proxies.
SSTP servers must be authenticated during the SSL/TLS phase. SSTP clients can optionally be authenticated during the SSL/TLS phase, and must be authenticated in the PPP phase. The use of PPP allows support for common authentication methods, such as EAP-TLS and MS-CHAP.
SoftEther VPN Server, a cross-platform open-source VPN server, also supports SSTP as one of its multi-protocol capability.
Similar functionality can be obtained by using open-source solutions like OpenVPN, however on Windows a third party client software must be installed due to the lack of native built-in VPN client.
For Windows, SSTP is available on Windows Vista SP1 and later, in RouterOS, and in SEIL since its firmware version 3.50. It is fully integrated with the RRAS architecture in these operating systems, allowing its use with Winlogon or smart card authentication, remote access policies and the Windows VPN client. The protocol is also used by Windows Azure for Point-to-Site Virtual Network.
SSTP was intended only for remote client access, it generally does not support site-to-site VPN tunnels.
SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the “TCP meltdown problem”.
There is an SSTP GUI client for Mac, which uses a modified sstp-client as backend which support server-name TLS extension called iSSTP.
Internet Key Exchange (version 2) is an IPSec based tunnelling protocol that was jointly developed by Microsoft and Cisco, and which is baked into Windows 7 and above. The standard is supported by Blackberry devices, and independently developed (and largely compatible) versions of IKE have been developed for Linux (through various open source implementations) and other operating systems. As always, we are wary of anything developed by Microsoft, but if open source versions are used then there should be no problem.
Dubbed VPN Connect by Microsoft, IKEv2 is particularly good at automatically re-establishing a VPN connection when users temporarily lose their internet connections (such as when entering or leaving a train tunnel).
Mobile users in particular, therefore, benefit the most from using IKEv2, which, because of its support for the Mobility and Multihoming (MOBIKE) protocol, also makes it highly resilient to changing networks. This is great news for cell phone users, for example, who connect their smart phones to a WiFi network while at home, but switch to mobile data use when out and about, or who regularly switch between hotspots.
IKEv2 is even more useful to Blackberry users, as it is one of the few VPN protocols supported by Blackberry devices.
It is not as ubiquitous as IPSec (it is supported on much fewer platforms), but is IKEv2 is considered at least as good as, if not superior to, L2TP/IPsec in terms of security, performance (speed), stability and the ability to establish (and re-establish) a connection.
IKEv2 is also a very good (secure and fast) protocol, especially for mobile users who may even prefer it to OpenVPN thanks to its improved ability to reconnect when an internet connection is interrupted. For Blackberry users, it is pretty much the only option available.
In order to understand encryption there are a number of key concepts that need to be grasped.
Encryption key length
Key length is the crudest way of determining how long a cipher will take to break, as it is the raw number of ones and zeros used in a cipher. Similarly, the crudest form of attack on a cipher is known as a brute force attack (or exhaustive key search), which involves trying every possible combination until the correct one is found.
Encryption used by VPN providers is invariably between 128-bits and 256-bits in key length (with higher levels used for handshake and data authentication), but what does this mean, and is 256-bit encryption really more secure than 128-bit encryption?
Well, to put these numbers into perspective:
- A 128-bit key cipher would require 3.4 x10(38) operations to reliably break
- In 2011 the fastest supercomputer in the word (the Fujitsu K computer located in Kobe, Japan) was capable of an Rmax peak speed of 10.51 petaflops. Based on this figure, it would take Fujitsu K 1.02 x 10(18) (around 1 billion) years to crack an 128-bit AES key by force
- The most powerful supercomputer in the world is the NUDT Tianhe-2 in Guangzhou, China. Almost 3 times as fast as the Fujitsu K at 33.86 petaflops, it would ‘only’ take it around a third of a billion years to crack a 128-bit AES key. That’s still a long time, and is the figure for breaking just one key
- A 256-bit key would require 2(128) times more computational power to break than a 128-bit one
- The number of operations required to brute force a 256-bit cipher is 3.31 x 10(65), roughly equal to the number of atoms in the universe!
Until the recent Edward Snowden revelations, it was generally assumed that 128-bit encryption was in practice uncrackable through brute force, and would be so another for another hundred years or so (taking Moore’s Law into account). In theory this still hold true, but the sheer scale of resources that the NSA seems to have thrown at cracking encryption has shaken many experts’ faith in these predictions, and system administrators around the world are scrambling to upgrade cipher key lengths.
It should be noted that the US government uses 256-bit encryption to protect ‘sensitive’ data (and 128-bit for ‘routine’ encryption needs). However, the method it uses is AES, which as we shall discuss below, is not without problems.
While encryption key length refers to the amount of raw of numbers involved, ciphers are the mathematics used to perform the encryption, and it is weaknesses in these algorithms, rather than in the key length, that often leads to encryption being broken.
By far the most common ciphers that you will likely encounter with VPN are Blowfish and AES. In addition to this, RSA is used to encrypt and decrypt a cipher’s keys, and SHA-1 or SHA-2 are used as a hash function to authenticate the data.
AES is now generally considered the most secure cipher for VPN use, and its adoption by the US government has only increased its perceived reliability, and consequently its popularity. However, there is reason to believe this trust may be misplaced.
AES, RSA, SHA-1 and SHA-2 were all developed and/or certified by the United States National Institute of Standards and Technology (NIST), a body that by its own admission works closely with the NSA in the development of its ciphers. Given what we now know of the NSA’s systematic efforts to weaken or built back doors into international encryption standards, there is every reason to question the integrity of NIST algorithms.
Although NIST has been quick to deny any wrong doing (‘NIST would not deliberately weaken a cryptographic standard’), and has invited public participation in a number of upcoming proposed encryption related standards in a move designed to bolster public confidence, the New York Times has accused the NSA of circumventing the NIST approved encryption standards by either introducing undetectable backdoors, or subverting the public development process to weaken the algorithms.
This distrust was further bolstered on September 17 2013, when RSA Security (a division of EMC) privately told customers to stop using an encryption algorithm that reportedly contains a flaw engineered by the National Security Agency.
Furthermore, Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) is an encryption standard engineered by NIST, and one that has been known to be insecure for years, with the Eindhoven University of Technology in the Netherlands noting in 2006 that an attack against it was easy enough to launch on ‘an ordinary PC’, and Microsoft engineers flagging up a suspected backdoor in the algorithm. Despite these concerns however, where NIST leads, industry will follow, and Microsoft, Cisco, Symantec and RSA all include the algorithm in their product’s cryptographic libraries, in large part due the fact that compliance with NIST standards is a prerequisite to obtaining US government contracts.
When you consider that NIST certified cryptographic standards are pretty much ubiquitous worldwide throughout all areas of industry and business that rely on privacy (including the VPN industry), this is all rather chilling. Perhaps precisely because so much relies on these standards, cryptography experts have been unwilling to face up to the problem – at least until Silent Circle, the company which closed its Silent Mail service rather than see it compromised by the NSA, announced in November 2013 that it planned to move away from NIST standards.
Thanks to BestVPN’s coverage of the issue, small but innovative VPN provider LiquidVPN has also started to experiment with non-NIST ciphers (and is currently using Camellia CBC on its Russia server), but this is the only VPN company we are currently aware of to show any signs of moving in this direction. Most VPN users will therefore have to make do with 256-bit AES as the best encryption standard currently available, but we hope that this will change in the future.
NSA attacks on RSA key encryption
One of the revelations that came out of the new information provided by Edward Snowden in September is that, “another program, codenamed Cheesy Name, was aimed at singling out encryption keys, known as ‘certificates’, that might be vulnerable to being cracked by GCHQ supercomputers.”
That these certificates can be ‘singled out’ strongly suggests that 1024-bit RSA encryption (commonly used to protect the certificate keys) is weaker than previously thought, and can be decrypted much more quickly than expected by the NSA and GHCQ. Once a certificate key has been decrypted, then all exchanges past and future will be compromised if non ephemeral key exchange is used (i.e. if, as is depressingly common practice, a single permanent private key is used to decrypt all data).
This means that many forms of encryption which rely on certificates and non ephemeral keys must be regarded broken, including SSL and TLS. This has huge implications for all HTTPS traffic.
The good news is that OpenVPN, which uses ephemeral (temporary) key exchanges, should not be affected. This is because with ephemeral key exchanges a new key is generated for each exchange, and there is therefore no reliance on certificates to establish trust. Even if an adversary were to obtain the private key of a certificate, they could not decrypt the communication. It is possible that a man in the middle (MitM) attack could target an OpenVPN connection if the private key has been comprised, but this would have to be specifically targeted attack.
Since news that the NSA (and GHCQ) can crack 1028-bit RSA encryption became public, some VPN providers at least have beefed up their key encryption to 2048-bits, or even up to 4096-bits.
Perfect Forward Secrecy
Another piece of good news is that solving this problem (even for SSL and TLS connections) is not difficult if websites implement perfect forward secrecy, a system whereby a new and unique (with no additional keys derived from it) private encryption key is generated for each session. (i.e. use of ephemeral key exchanges). On a positive note, since this article discussing PFS in detail was written, use of ephemeral keys has greatly increased (although sadly is not universal.) Where OpenVPN uses PFS, it should be secure, even against the NSA (as far as we know.)
Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on
What you should take away from this article is that OpenVPN remains a very secure protocol (and arguably the best VPN protocol), and that many VPN companies are working to strengthen their implementation of it. It would be great if providers also started to move away NIST standards, but for that we shall to wait and see.
- PPTP is very insecure (even its co-creator Microsoft has abandoned it, and it has been compromised by the NSA) and should therefore be avoided. While its ease of setup and cross platform compatibility are attractive, L2PT/IPsec has the same advantages and is much more secure
- L2TP/IPsec is a good VPN solution for non-critical use, although it has been severely compromised / weakened by the NSA. However, for a quick VPN setup without the need to install extra software it remains useful, particularly for mobile devices where OpenVPN support remains somewhat patchy
- OpenVPN is easily the best all round VPN solution, despite needing third party software on all platforms. It is reliable, fast, and (most importantly) secure (even against the NSA), although it usually needs a bit more setting up than the other protocols
- IKEv2 is also a very good (secure and fast) protocol (if open source implementations are used), especially for mobile users who may even prefer it to OpenVPN thanks to its improved ability to reconnect when an internet connection is interrupted. For Blackberry users, it is pretty much the only option available
- SSTP offers most of the advantages of OpenVPN but only in a Windows environment. This does mean that it is better integrated into the OS, but it is poorly supported by VPN providers thanks to this limitation. In addition to this, its proprietary nature and the fact that is was created by Microsoft mean that we for one don’t trust it
So basically, where possible you should always choose OpenVPN (or possibly IKEv2 if the option is available, especially for mobile devices). If you need a quick and dirty solution (such as for protecting your phone from casual criminals when connecting to public WiFi hotspot) then L2TP/IPsec will probably do, but given the increasing availability of OpenVPN apps for mobile devices (especially Android), we would still prefer to use OpenVPN.
PureVPN’s business remote access solution is pre-loaded with:
- NAT Firewall Protection
- DDoS Protection
- AES 256-bit Encryption
- Split Tunneling
- Secure Protocols
- Stealth Browser for Extra Protection and Speed
- Servers in 140+ geographic locations
- Complete Online Protection
- And Numerous Other Features
Important update: VPN and the WebRTC bug
To see whether your browser is vulnerable to the WebRTC ‘bug’, visit ipleak.net(with your VPN enabled). WebRTC can be easily disabled in Firefox by changing the media.peerconnection.enabled setting to false (see here for full instructions), and can be disabled in Chrome using the WebRTC Network Limiter extension and select “Use my proxy server (if present)”.
Don’t forget to check out the companion pieces to this article: VPN encryption terms explained (AES vs RSA vs SHA etc.), and A Complete Guide to IP Leaks.