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
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.
|– usually considered very secure but see cons
– easy to set up
– available on all modern platforms cons
– faster than openvpn
|– may be compromised by the nsa (unproven)
– likely deliberately weakened by the nsa ( unproven)
– can struggle with restrictive firewalls
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…
|– highly configurable
– very secure (probably even against the nsa, if perfect forward secrecy is used)
– can bypass firewalls
– can use a wide range of encryption algorithms
– open source (and can therefore be readily vetted for back doors and other nsa style tampering)
|– needs third party software
– can be fiddly to set up
– support on mobile devices is improving, but is not as good as on the desktop
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.
|– very secure (depends on cypher, but usually very strong aes)
– completely integrated into nt (windows vista sp1 windows 10)
– microsoft support
– can bypass most firewalls
|– only native to a microsoft windows environment but can be used on other operating systems with client software
– proprietary standard owned by microsoft so cannot be independently audited for back doors and suchlike
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.
|– faster than pptp, sstp and l2tp, as it does not involve the overhead associated with point-to-point protocols (ppp)
– very stable – especially when switching network or reconnecting after a lost internet connection
– very secure – supports aes 128, aes 192, aes 256 and 3des ciphers
– easy to setup (at least at the user-end!)
– protocol is supported on blackberry devices
– uses perfect forward secrecy
|– not supported on many platforms
– implementing ikev2 at the server-end is tricky, which is something that could potentially result in issues developing
– we only trust open source implementations
in order to understand encryption there are a number of key concepts that need to be grasped.
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:
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.
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.
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.
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.
we use only the highest strength encryption to protect your internet connection. this means all your network traffic is encrypted with aes-256, key exchange is done with 2048-bit rsa, and hmac with sha256 is used for message authentication.
we have carefully selected our encryption cipher suites to only include ones that have perfect forward secrecy. this means that your encrypted traffic cannot be captured and decrypted later if the encryption key from a subsequent session gets compromised. with each connection, we generate a new encryption key, so a key is never used for more than one session.
we use only vpn protocols which are known to be secure – ikev2/ipsec and openvpn. protonvpn does not have any servers that support pptp and l2tp/ipsec, even though they are less costly to operate. by using protonvpn, you can be confident that your vpn tunnel is protected by the most reliable protocol.
in addition to strong technical security, protonvpn also benefits from strong legal protection. because we are based in switzerland, protonvpn is protected by some of the world’s strongest privacy laws and remains outside of us and eu jurisdiction. this means that unlike vpn providers based in a fourteen eyes country, we cannot be coerced into spying on our users.
we are one of the only vpn companies that provide transparency so you know exactly who is running the service. our team has a long track record in security, having previously built protonmail – the world’s largest encrypted email service. whether it is challenging governments, educating the public, or training journalists, we have a long history of fighting for privacy online and contributing to the open source community.
we have gone to extreme lengths to protect protonvpn’s secure core servers to ensure their security. critical infrastructure in switzerland is located in a former swiss army fallout shelter 1000 meters below the surface. similarly, our iceland infrastructure resides in a secure former military base. our servers in sweden are also located in an underground data center. by shipping our own equipment to these locations, we ensure that our servers are also secure at the hardware level.
if you haven’t done research on the various vpn providers available, i definitely recommend that you take a look at how to find a trustworthy vpn service. i think you’d be surprised at how deceptive the majority of the big names are, and that’s why i have the most trust in protonvpn. i’m not even being paid for this plug, i simply want to promote their transparency.
when you're a little too careless about virtualizing your domain controllers, cloning, migrating, backing up and restoring, returning from vacation… Read More
systemd is new service manager for linux. it's a replacement for all previous init systems (sysv/sysvinit & ubuntu's upstart) and… Read More