VPN encryption is not an easy subject. Really, it isn’t! When it comes to understanding the terminology used to describe how secure a VPN connection is, things can get very confusing very quickly (a situation not helped by the fact that many VPN providers can be slapdash to the point of misleading when describing the encryption they use).
This guide, then is aimed at untangling the various terms when explaining VPN encryption, and serves as a companion piece to our article on PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2.
A VPN protocol is the set of instructions (mechanism) used to negotiate a secure encrypted connection between two computers.
We look at the different VPN encryption protocols in our article on PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2. Note that the VPN protocol is separate from encryption and authentication methods used, which vary depending on the protocol.
PPTP, for example, uses MS-CHAP v2 (which is very insecure), while L2TP almost always uses the IPSec authentication suite, hence you will often see the term L2TP/IPSec. In fact, even if a provider only refers to either LT2P or IPSec (as some do), it almost certainly actually means L2TP/IPSec.
OpenVPN is now the industry standard VPN protocol used by commercial VPN services, and for good reason. It is very secure, and can be used on almost all VPN capable devices (with the notable exception of Blackberry devices).
We therefore recommend using OpenVPN wherever possible, and the rest of this article is primary concerned with OpenVPN*.
* OpenVPN uses the OpenSSL encryption library extensively, as well as the SSLv3/TLS protocol. SSTP provides a mechanism to transport PPP or L2TP traffic through an SSLv3 channel. Thanks to its use of SSL, many of the points made about OpenVPN below also apply to SSTP.
(also referred to as key encryption or certificate encryption)
In order to securely negotiate a VPN connection, SSL (and therefore OpenVPN and SSTP) usually uses the RSA asymmetric public-key cryptosystem (asymmetric because a public key is used to encrypt the data, but a different private key is used to decrypt it).
RSA acts as an encryption and digital signature algorithm used to identify TLS/SSL certificates, and has been the basis for security on the internet for the last 20 years or so.
However, it has been demonstrated as of 2010 that 1024-bit RSA (RSA-1024) private key encryption can be cracked (and probably has been by the NSA), leading Google in 2013 to upgrade all of its SSL certificates to the much secure 2048-bit RSA key length, a move copied by most of the security industry.
RSA-2048 key encryption is considered secure, although a case can be made for choosing even stronger 3072-bit or 4096-bit RSA encryption. RSA-2048 is now the minimum standard for commercial VPN providers.
An alternative (rival) handshake that is sometimes used by OpenVPN is the Diffie-Hellman cryptographic key exchange, but this has recently caused huge controversy over its re-use of a limited set of prime numbers, which make it vulnerable to being cracked by a powerful adversary such as the NSA.
The newer Elliptic curve Diffie-Hellman (ECDH) cryptography is not vulnerable to this attack, as it uses the properties of a particular type of algebraic curve instead of large prime numbers to encrypt connections.
One advantage that any Diffie-Hellman key exchange has over RSA is that it allows Perfect Forward Secrecy (PFS) to be used. This means that for each new SSL connection made, a new set of keys is generated (and are therefore referred to as ephemeral keys). This makes the job of an adversary much more arduous, as it would have to crack a new key each time a new SSL connection is made.
However, although RSA does not allow for PFS, OpenVPN does (if implemented). This the major reason why OpenVPN is still considered secure against even the NSA.
Because it can cause confusion, we should also note that the RSA cryptosystem has nothing to do with the disgraced US tech firm RSA Security LLC, which deliberately weakened its flagship BSAFE encryption products after being bribed $10 million by the NSA.
SHA hash authentication
(also referred to as data authentication or hash message authentication code (HMAC))
It creates a unique fingerprint of a valid SSL certificate that can be validated by any OpenVPN client. If the certificate is tampered with, this will be immediately detected (even the tiniest change is detectable), and the connection refused.
This is important in preventing a Man-in-the-middle (MitM) attack, where an adversary may attempt to divert your OpenVPN connection to one of its own servers instead of that of your VPN provider (for example by hacking your router). If an adversary can crack the hash of your provider’s genuine SSL certificate, it can reverse the hash to create a forged certificate, so VPN software would authenticate the connection as genuine.
The most common version of SHA used on the internet is SHA-1 (160-bit), underpinning more than 28 percent of existing digital certificates (including those used by many VPN providers.) Unfortunately, SHA1 is broken.
This has been known for some time, and Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017. However, a new research paper suggests that it may be possible to crack SHA-1 before this cut-off date.
In August this year NIST announced that SHA-3 was the new hash standard, after flirting with SHA-2 since 2010. Although no successful attacks against SHA-2 have been recorded, its algorithmic similarity to SHA-1 make SHA-3 the preferred standard.
It is a shame, then, that OpenVPN only supports SHA-1 and SHA-2 (up to SHA-384), not SHA-3. As of the time of writing this article (November 2015), SHA-1 is probably still secure (although who knows what the NSA is capable of). It really is time, however, that VPN providers moved on to SHA-2 (SHA-256 or SHA-384) instead.*
*After in-depth discussions with AirVPN, I now understand that as long as packet authentication is enabled, use of HMAC SHA1 for OpenVPN authentication is not a weakness, as HMAC SHA1 is much less vulnerable to collision attacks than standard SHA1 hashes (for example, you would need to break HMAC in order to reach the underlying hash in order to start collisions attempts on it). Mathematical proof of this is available in this paper.
(also referred to as data encryption)
The VPN protocol, handshake, and data authentication are all designed to ensure that your VPN connection to the VPN server is secure. Your actual data, however, is encrypted using a cipher.
By default, OpenVPN uses the 128-bit Blowfish cipher, which is considered secure for most casual purposes, but 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’.
Unfortunately, Twofish is not supported by OpenVPN, so the NIST-approved AES cipher has become the industry-wide “gold standard” for VPN encryption. AES-256 is used by the US government for protecting ‘secure’ data, and is considered very secure. 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.
Some VPN providers have flirted with using non-NIST ciphers supported by OpenVPN, such as Camellia, but for whatever reason, little has really come of this. As such, AES remains king when it comes to VPN ciphers (although if OpenVPN ever gets around to supporting Twofish or Threefish, things may be different).
AES is usually available in 128-bit and 256-bit versions (192-bit AES also exists, but we hardly ever see it in the wild!).
AES-128 remains secure as far as anyone is aware, but given what we now know about the extent of the NSA’s assault on encryption standards, most experts agree that AES-256 provides a higher security margin (although there is some debate about this, as AES-128 has a stronger key schedule than AES-256.)
Other considerations / notes
All versions of SHA, RSA, and AES were 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.
Unfortunately, at this point in time, VPN users have little choice but to use NIST approved standards, but it is worth bearing in mind our unease at this situation. We discuss our beef with NIST in greater detail in our PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2 article.
Encryption comes at a cost
Encrypting and decrypting data takes processing power, and encryption increases the amount of data transmitted over the internet. This means that the higher the encryption settings used by you or your VPN provider, the slower your internet connection will be.
This will not usually make a bit difference, but sometimes it can. This is particularly the case with smaller providers who servers can struggle to cope with limited bandwidth and large numbers of users, which is certainly not helped by increasing the required computational overhead!
Block Cipher Mode
When reviewing providers’ descriptions of the VPN encryption they use (or when inspecting an OpenVPN config file) you may come across the term “CBC cipher block mode”, or see “CBC” appended to the cipher entry (e.g. AES-256-CBC).
This refers to the Block cipher mode of operation, which is a very complex and highly technical subject. The good news for this article is that Cipher Block Chaining (CBC) is the only block cipher mode we have seen supported by commercial VPN providers (to see a full list of ciphers supported by OpenVPN, enter “openvpn –show-ciphers” in a Command prompt/Terminal window).
Although CBC may theoretically have some vulnerabilities, the general consensus is that CBC is secure (and is recommended in the OpenVPN manual). Our basic advice when it comes to explaining VPN encryption, therefore, is that CBC is fine, and given that you are unlikely to encounter any other Block cipher mode, is not worth worrying about anyway.
VPN Encryption Summary
VPN protocol (PPTP, L2TP/IPSec, OpenVPN, SSTP, IKv2) – the set of instructions used to secure a VPN network
Handshake (RSA-1024, RSA-2048, RSA-3072, RSA-4096, EEC, ECDH) – used to securely negotiate a VPN connection
Hash authentication (SHA-1, SHA256, SHA-3) – creates a unique fingerprint used to authenticate an SSL connection
OpenVPN cipher (Blowfish-126, AES-128, AES-192, AES-256, Camellia128, Camellia-192, Camellia-256) – the encryption algorithm used to protect your actual data.
As a point of reference, the minimum default settings for the OpenVPN protocol are:
Hash authentication: SHA-1 (HMAC)
So what constitutes “secure” settings for a VPN connection? Well, that is a little like asking “how long is a piece of string,” and depends heavily on your threat model (who you are worried about being secure against). That said, our minimum recommendation for a “secure” VPN connection that should be resistant against any known form of attack for the foreseeable future is:
VPN Protocol: OpenVPN with Perfect Forward Secrecy enabled
Hash authentication: SHA1 (HMAC)