Several months ago, security researcher Ahamed Nafeez disclosed the VORACLE compression attack against encrypted OpenVPN sessions which could allow attackers to decrypt encrypted VPN traffic if plaintext traffic such as HTTP was being tunneled through the VPN, and the VPN had compression enabled.
We've been saying for years that you should be using encrypted protocols only, even when your traffic is being encrypted by OpenVPN, but even then we know that some people would still use plaintext protocols while on the VPN.
So the plan was to do what some other VPN providers were doing, that is to simply disable compression by pushing the OpenVPN option "--comp-lzo no" from the server to the client. However, during our own research we found that the "--comp-lzo no" option doesn't have the intended effect in all OpenVPN versions.
In certain mixtures of the client running OpenVPN 2.3 and the server running 2.4, "--comp-lzo no" doesn't disable compression, it instead enables LZO compression with the stub algorithm, which means it's still vulnerable to VORACLE.
See:
https://community.openvpn.net/openvpn/ticket/952
https://community.openvpn.net/openvpn/ticket/861
It seems the only way to completely disable compression when the client config has "--comp-lzo" in it is to remove that from the client and server configs. For a while now, we've been offering configs with more recent OpenVPN options and the more efficient Elliptic curve cryptography, but to continue supporting clients with older versions of OpenVPN, we've also had configs which only use traditional RSA cryptography.
In those newer ECC configs, "--compress lz4" was used, and it's easy enough to push from the server "--compress" so that compression is disabled (but the framing for it is still there in case the client wants to use it anyways).
In those older RSA configs, "--comp-lzo" is used on both sides so that adaptive compression is enabled, which tells OpenVPN to compress traffic that's not already compressed (for example, HTTP traffic not compressed with gzip).
To completely disable compression for those older RSA configs, we would need them to update their configs. Since we don't do that often, we're using this opportunity to add/change features in all the configs. With the recent release of OpenSSL 1.1.1, new features are now available that we'd like to use. What follows is a brief summary of the old RSA/ECC configs, then a summary of the new setup we'll be using from now on.
Old setup
The old setup used different OpenVPN instances for different operating systems. Windows users got their own set of instances to connect to, and Linux/Android/Mac/etc. had their own instances. At least for RSA configs. The newer ECC configs were OS indepedent. The difference between the two RSA instances were minor OS dependent performance related tweaks in OpenVPN (--fragment, --txqueuelen, --sndbuf, --rcvbuf, --mssfix, etc.). Recent tests we've done have shown that the benefits of those tweaks are neglible at best, so the new setup won't be using them. See the OpenVPN manual for explanations of the above and below options.
For the old Windows/Linux RSA instances, the OpenVPN settings were:
| --tls-cipher |
TLS-DHE-RSA-WITH-AES-256-CBC-SHA |
| --ca |
2048-bit RSA TLS certificate |
| --cert |
2048-bit RSA TLS certificate |
For the old OS independent ECC instances, the OpenVPN settings were:
| --tls-cipher |
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 |
| --ca |
256-bit EC (~3072-bit RSA) |
| --cert |
256-bit EC (~3072-bit RSA) |
New setup
In the new setup, everything will be OS independent. That means all the configs will work on any operating system.
There will now be 4 different instances per IP. RSA, ECC, Ed25519, and Ed448 (explained below).
RSA will use ports 1-5059 and 5063-29999. ECC will use port 5060, Ed25519 will use port 5061, and Ed448 will use port 5062.
Ports 30000-65535 are already reserved for port forwarding.
The cryptographic strength used will depend on your OpenVPN and/or OpenSSL version.
The newer the version of OpenVPN/OpenSSL you have, the better the crypto.
Also, we will be keeping a minimal number of old instances up so people who don't upgrade will still be able to connect to something.
In those instances, almost everything is the same. For the RSA ones, the CA certificate is still the same 2048-bit RSA, but the server certificate has been bumped up to 8192-bit.
Negotiable ciphers has also been enabled, allowing those connecting from an OpenVPN that supports GCM (AEAD) to use that instead of CBC.
So far, the only problem we've seen is a case where an ARM6 device would time out before connecting because of the 8192-bit server cert.
In that case, the solution was to change in their config "hand-window 17" to "hand-window 120".
But if you're going to be changing your config, you might as well update to the new ECC ones that have a smaller key size.
RSA
As with the old RSA setup, these new RSA configs are still meant to provide backwards compatibility for anyone still using older versions of OpenVPN or OpenSSL.
They will work with OpenVPN 2.3.2 through OpenVPN 2.4.6, and OpenSSL 1.0.0 through 1.1.1
While researching ways to increase the cryptographic strength of the old RSA instances (aside from simply increasing the size of the keys), we realized that elliptic curve support was added to OpenSSL way back in 2005.
It was only recently supported in OpenVPN 2.4.0, but that just applies to server certificates (--cert).
For CA certificates (--ca), OpenVPN delegates the processing directly to OpenSSL.
That means, even in OpenVPN 2.3.x, you could use EC certificates for the CA cert (but not the server cert).
So we did that.
For the three scenarios below, OpenVPN will always use the options:
| --ca |
521-bit EC (~15360-bit RSA) |
Plus an additional HMAC layer provided by --tls-auth
The only thing that will change based on your OpenVPN/OpenSSL version is --tls-cipher and --cipher
If you have at least OpenVPN 2.4.0 and OpenSSL 1.1.0, you'll receive:
If you have a slightly older version of OpenVPN or OpenSSL, you'll receive:
| --tls-cipher |
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 |
If you have a very old version of OpenVPN or OpenSSL, you'll receive:
| --tls-cipher |
TLS-DHE-RSA-WITH-AES-256-CBC-SHA |
ECC
Like the old ECC configs, the new ones will sacrifice compatibility for the sake of better crypto.
They work with OpenVPN 2.4.0 through 2.4.6, and OpenSSL 1.0.1d through 1.1.1
For the two scenarios below, OpenVPN will always use the options:
| --ca |
521-bit EC (~15360-bit RSA) |
| --cert |
521-bit EC (~15360-bit RSA) |
Plus an additional HMAC layer provided by --tls-crypt
The only thing that will change based on your OpenVPN/OpenSSL version is --tls-cipher and --cipher
If you have at least OpenVPN 2.4.0 and OpenSSL 1.1.0, you'll receive:
If you have a slightly older version of OpenVPN/OpenSSL, you'll receive:
| --tls-cipher |
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 |
Ed25519
The Ed25519 configs use all the same crypto as the above ECC setup, except the CA and server certificates use Ed25519.
Because of that, OpenSSL 1.1.1 is required. OpenVPN can be any version from 2.4.3 to the latest.
See https://ed25519.cr.yp.to for more info on Ed25519.
Ed448
The Ed448 configs use all the same crypto as the above ECC setup, except the CA and server certificates use Ed448.
Because of that, OpenSSL 1.1.1 is required. OpenVPN can be any version from 2.4.3 to the latest.
See https://eprint.iacr.org/2015/625.pdf for more info on Ed448.
