cryptostorm vs ivpn comparison

[df]

This is a response to https://twitter.com/prince_ghee/status/ ... 6113477633, since this would be way too many characters for twitter's limit.

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:
TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
and our ECC configs use:
TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
with support for TLSv1.3 added via the server-side:
--tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

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)

which is probably secure enough, but it's not the most efficient option available. Our ECC configs use 521-bit elliptic curves instead:

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)

According to the chart on https://archive.is/G7TQq (https://www.nsa.gov/business/programs/elliptic_curve.shtml archived), a 521-bit EC key is roughly the equivalent of 15360-bit RSA. So it's much more secure, but since the key space is smaller and the algorithm is more efficient, there's less overhead.
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

[donmccarlos]

I've tried them but the speeds were really bad for me compared to most other providers.

[donmccarlos]

Any update on this. Make the comparison more easy to understand.

[df]

@donmccarlos
What part are you having trouble understanding?

[Guest]

Thanks for the amazing information.It would be really appreaciated.But do you have any other update to make the comparison easy to understand

[kriptopoulin]

Any more update so we can more easily understand.