We can't evaluate whatever IVPN is doing server-side since that information isn't public, so we're only going to take a look at their OpenVPN client-side configs and infer what we can from those.
Their UDP configs are at https://www.ivpn.net/releases/config/iv ... config.zip and their TCP configs are at https://www.ivpn.net/releases/config/iv ... ig-tcp.zip
All of their configs are pretty much the same, only the host/CN names are different, and the TCP configs have "proto tcp-client" while the UDP ones have "proto udp".
The first thing that catches my eye is that they're still using the "AES-256-CBC" cipher for the "data channel" (the thing that actually encrypts your traffic). That cipher is still considered secure, but it's not the best available anymore. The more efficient AES-256-GCM has been supported in OpenVPN since version 2.4.0, which came out in 2016. Our recommended configs have plenty of technical details on this at line https://github.com/cryptostorm/cryptost ... P.ovpn#L87
We added support for AES-256-GCM as soon as it was available, around 5 years ago. These days we also support CHACHA20-POLY1305, which became available with OpenVPN 2.5.0's release in late 2020. I didn't do any test connects to IVPN, but it is possible that their server-side config is doing cipher negotiations when you connect, so that AES-256-GCM or CHACHA20-POLY1305 is used instead of the AES-256-CBC specified in the config, if the client supports it. That's how our RSA configs work, but we don't recommend using those since they're just for backwards compatibility, and our elliptic curve cryptography (ECC) configs use better crypto.
Next is the TLS ciphers they're using, "TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA". Those ciphers are used to encrypt OpenVPN's "control channel", which is used to establish a TLS session that'll be used later to exchange cipher and HMAC keys to protect the data channel. There's three cipher suites specified here, separated by semi-colons, and these ciphers are negotiated to whichever the client prefers or supports. The TLS is only as strong as the weakest link, since downgrade attacks are possible in some man-in-the-middle scenarios. According to https://ciphersuite.info/search/?q=TLS_ ... 56_CBC_SHA, the second cipher is considered weak.
Our RSA configs on the other hand specify the much more secure:
and our ECC configs use:
with support for TLSv1.3 added via the server-side:
The CA certificate embedded in their config is using 4096-bit RSA:
Code: Select all
[root@b ~]# sed -ne ' /-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p /-END CERTIFICATE-/q' ivpn_france.ovpn|openssl x509 -noout -text|grep -B1 -- -Key Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit)
Code: Select all
[root@b ~]# sed -ne ' /-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p /-END CERTIFICATE-/q' cryptostorm_france.ovpn|openssl x509 -noout -text|grep -B1 -- -Key Public Key Algorithm: id-ecPublicKey Public-Key: (521 bit)
and just for fun, our RSA instances are doing 8192-bit RSA.
Another thing I see is that they're doing "comp-lzo no". This is to disable compression, which is a good idea since using compression in OpenVPN can make you vulnerable to attacks like the VORACLE one described at https://github.com/skepticfx/voracle. The problem is that "comp-lzo no" doesn't always have the intended effect. In our research, we found that compression isn't always disabled whenever there's a certain combination of different client and server OpenVPN versions being used. This is a known bug described on https://community.openvpn.net/openvpn/ticket/952 and https://community.openvpn.net/openvpn/ticket/861. It appears that the only way to be completely sure compression won't be used is to remove "comp-lzo" from both server-side and client-side configs.
And finally, they're using "tls-auth". According to OpenVPN man page, "tls-auth adds an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack". Using tls-auth is better than nothing, but there's a newer "tls-crypt" option that's been available since 2016, it does authentication AND encryption of the TLS control channel. We've had it in our ECC configs for about 5 years now. There's also an even newer v2 of tls-crypt that we'll be supporting soon, it's docs are at https://github.com/OpenVPN/openvpn/blob ... ypt-v2.txt