Is using static keys safe?

[dougiepunk 1]

Looking at the AirVPN .ovpn files, it seems that AirVPN uses static keys [staff edit: NO - see next post]. According to OpenVPN.net,
Static Key disadvantages

• Limited scalability -- one client, one server
• Lack of perfect forward secrecy -- key compromise results in total disclosure of previous sessions
• Secret key must exist in plaintext form on each VPN peer
• Secret key must be exchanged using a pre-existing secure channel

This would seem to suggest that perfect forward secrecy is not enabled. The "Limited scalability -- one client, one server" bit also seems to suggest that shared IPs are not being used. If these points are true, then AirVPN is a lot less rsecure than I thought! Could you please explain?

[Staff 9972]

Hello,
 
no, those points are all blatantly false. We don't understand how you could infer those from the .ovpn file, which on the contrary should have led you to opposite conclusions.
 
Fist and foremost, AirPVN OpenVPN daemons operate in tls-mode. From the manual:

 

TLS mode is the most powerful crypto mode of OpenVPN in both security and flexibility. TLS mode works by establishing control and data channels which are multiplexed over a single TCP/UDP port. OpenVPN initiates a TLS session over the control channel and uses it to exchange cipher and HMAC keys to protect the data channel. TLS mode uses a robust reliability layer over the UDP connection for all control channel communication, while the data channel, over which encrypted tunnel data passes, is forwarded without any mediation. The result is the best of both worlds: a fast data channel that forwards over UDP with only the overhead of encrypt, decrypt, and HMAC functions, and a control channel that provides all of the security features of TLS, including certificate-based authentication and Diffie Hellman forward secrecy.

 
 
That's exactly what it happens. Additionally, DH keys are 4096 bit.
 
 

To use TLS mode, each peer that runs OpenVPN should have its own local certificate/key pair ( --cert and --key ), signed by the root certificate which is specified in --ca.

 
And that's what you see in the .ovpn file.
 
An element that might have contributed to your confusion is that you don't see in the .ovpn file of your client the "tls-client" directive to enable TLS mode.
 
That's because the directive "client" is used instead, which is expanded into "tls-client" + "pull".
 
Again, reading the manual helps:
 

--client

A helper directive designed to simplify the configuration of OpenVPN's client mode. This directive is equivalent to:
 
pull
tls-client

 

 

You can easily check all of the above by looking at your OpenVPN client logs pertaining to a connection to any VPN server. You will see something like:

... - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
... - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
... - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
... - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
... - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

 

Enjoy AirVPN!

Kind regards

[dougiepunk 1]

Thank you clearing that up. This does bring up a second qustion, though. Given the weakness SHA-1 HMAC authentication, should AirVPN not use SHA256?

[dougiepunk 1]

(http://arstechnica.com/security/2015/10/sha1-crypto-algorithm-securing-internet-could-break-by-years-end/)

[Staff 9972]

Thank you clearing that up. This does bring up a second qustion, though. Given the weakness SHA-1 HMAC authentication, should AirVPN not use SHA256?

 

Hello!

The premise is wrong, there's no known such "weakness" in HMAC SHA1, in the sense that in HMAC SHA1, SHA1 collisions based attack is currently irrelevant. The article you linked refers to SHA1, not HMAC SHA1 (for a precise description of the reason, keep reading).

 

See also for a quick, qualitative confirmation https://www.schneier.com/blog/archives/2005/02/sha1_broken.html :

This attack builds on previous attacks on SHA-0 and SHA-1, and is a major, major cryptanalytic result. It pretty much puts a bullet into SHA-1 as a hash function for digital signatures (although it doesn't affect applications such as HMAC where collisions aren't important).

 

We'll say more, even HMAC MD5 can still be considered unaffected by collisions, see for example http://crypto.stackexchange.com/questions/9336/is-hmac-md5-considered-secure-for-authenticating-encrypted-data

 

The article you linked in your other post talks about SHA1 used for digital signatures (of certificates or anything else). That's really a problem because real world attacks are estimated to be feasible in the near future (2017).

 

Switching Data Channel packet authentication digest in our setup would be swift on our side, but would break compatibility with customers using OpenVPN/OpenSSL versions that can't support it. For this reason, we will carefully evaluate the switch, with no hurry.

 

See here:

http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html

 

Abstract: HMAC was proved by Bellare, Canetti and Krawczyk (1996) to be a PRF assuming that (1) the underlying compression function is a PRF, and (2) the iterated hash function is weakly collision-resistant. However, recent attacks show that assumption (2) is false for MD5 and SHA-1, removing the proof-based support for HMAC in these cases. This paper proves that HMAC is a PRF under the sole assumption that the compression function is a PRF. This recovers a proof based guarantee since no known attacks compromise the pseudorandomness of the compression function, and it also helps explain the resistance-to-attack that HMAC has shown even when implemented with hash functions whose (weak) collision resistance is compromised. We also show that an even weaker-than-PRF condition on the compression function, namely that it is a privacy-preserving MAC, suffices to establish HMAC is a secure MAC as long as the hash function meets the very weak requirement of being computationally almost universal, where again the value lies in the fact that known attacks do not invalidate the assumptions made.

 

 

Now, in spite of all of the above, let's take a conservative approach. SHA1 collisions can easily become real-world feasible within a couple of years. So, not later than 2017, we will (most probably) assist to the first time practical collision attacks breaking SHA1. In this scenario, let's imagine that someone can figure out how to turn that into a pre-image attack against HMAC, making both conditions 1 and 2 of the above cited paper NOT met. In this case, switching digest will be mandatory, because we would be in a scenario where the packet-injection resistance of OpenVPN would be potentially compromised. Therefore, in order not to cut out customers without any reasonable, valid reason, we will prepare a switch with no time pressure but with careful planning.

 

EDIT: PRF = Pseudo Random Function

 

Kind regards

[BDK2015 2]

[Edit from Staff] We have merged your message in this thread because of https://airvpn.org/topic/15702-is-using-static-keys-safe/?do=findComment&comment=33246

 

Hi everyone! I am an experienced VPN user that has recently signed up with AirVPN. Coming from many different providers, they usually provided me the privelage of picking me own protocols, I am okay with the fact that AirVPN uses AES-256 encryption, but would like to see SHA-256 data authentication as SHA-1 data authentication had it's first successful collision attack recently. It's awesome being a part of the AirVPN family and you can expect to see me helping other users around the forum.

 

Thanks,

 

 

 

SHA-1 Collision Attack: http://it.slashdot.org/story/15/10/09/1425207/first-successful-collision-attack-on-the-sha-1-hashing-algorithm?utm_source=feedly1.0mainlinkanon&utm_medium=feed