Security of AirVPN website

[p4171768 0]

When logging in to the airvpn.org website, I notice that it is protected with TLS 1.0.

According to an article from Sept 2011 ( http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ ) this protocol has been broken.

I notice that many websites (Facebook, Google, Dropbox) are now using TLS 1.1, which seems to still be considered secure, while Dropbox even uses AES256 encryption for their TLS implementation.

 

Is it possible that AirVPN update their website to 1.1, especially considering login credentials and ovpn files are transferred through it?

[Staff 9782]

Hello,

 

TLS 1.1 and 1.2 are available on 212.117.180.25. If you wish to use them right now you should resolve airvpn.org to that IP address and force the browser to TLS 1.1 or 1.2. AES-256 is available as well.

 

TLS 1.1 and 1.2 on the other two public frontend servers are planned to be implemented within the next 24 hours.

 

Please note that TLS 1.0 and SSL 3.0 will remain available at the moment, in order not to cut out of the system Firefox, Chromium, Chrome, Iceweasel and many other browsers versions that do not support TLS 1.1 and 1.2 (perhaps more than 3/4 of our users) or that support them but require explicit user configuration to enable them.

 

Kind regards

[itsrumsey 0]

AirVPN staff, you are so fast and awesome.

[p4171768 0]

Thank you! I didn't expect such a quick modification to the system.

Will the AirVPN application utilize the newer protocol since the server side now does?

[Staff 9782]

Hello,

 

TLS 1.1 and TLS 1.2 are now available also on the primary frontend server airvpn.org (95.211.138.143). All ciphers are supported, AES-256 included.

 

Kind regards

[Staff 9782]

Thank you! I didn't expect such a quick modification to the system.

Will the AirVPN application utilize the newer protocol since the server side now does?

Hello!

 

Not with the current client, because TLS 1.2 is supported only since .NET framework 4.5.

 

However, with regards to BEAST, CRIME, Lucky Thirteen and various BEAST-dubbed attacks & exploits, this does not appear relevant, because such attacks rely on cookies and javascript (one of the key of the attack is decrypting a session cookie with a relatively low number of attempts; the number of attempts is still quite high for a single session, so the attack is dubbed for example with javascript, to open many multiple sessions), which are not used by the client.

 

The most-successful known attacks against TLS 1.0 require at least 2-3 minutes to be completed, and the client not only will not open a myriad of sessions, but it will also timeout well in advance. The next client release for Windows, Linux and OS X will be under GPL so you will be able to examine the source code.

 

About OpenVPN, the original message by James Yonan stands:

 

 

We've gotten some questions about whether OpenVPN is vulnerable to the

"BEAST" exploit.

 

At the time of this writing, the details of the "BEAST" exploit haven't

been released yet, but the general consensus is that it exploits the

known-IV weakness in SSL and TLS 1.0 that is discussed by Bard back in 2004:

 

http://eprint.iacr.org/2004/111.pdf

 

The vulnerability is present in all versions of SSL and TLS 1.0 but not

TLS 1.1 or higher (OpenVPN currently uses TLS 1.0).

 

One of the common workarounds for this vulnerability is to have the SSL

implementation add empty fragments into the application data stream.

OpenSSL has implemented this workaround since 0.9.6d (9 May 2002).

 

See http://www.openssl.org/~bodo/tls-cbc.txt

 

So the bottom line is that even though OpenVPN uses TLS 1.0 which is

technically vulnerable, the OpenSSL workaround added in 0.9.6d

effectively protects TLS 1.0 from this vulnerability, and hence OpenVPN

as well.

 

Now if OpenSSL patched this back in 2002, you might be wondering why

it's an exploitable vulnerability today.  I think the answer is that

while OpenSSL patched the vulnerability, NSS did not (NSS is an

alternative to OpenSSL that is widely used in web browsers).

 

In fact, if you look at this recent commit to NSS by the Chromium

project (presumably to address the BEAST exploit), you see the same

workaround being added to NSS that was added to OpenSSL 9 years ago.

 

https://src.chromium.org/viewvc/chrome?view=rev&revision=90643

 

James

 

Yonan went straight to the roots, without even having the need to consider all the browsers features, side-support web sites, injection etc. required to BEAST and CRIME to have a hope to succeed, to which OpenVPN is not "vulnerable".

 

Feel free anyway to add your considerations, and remember that we do not and we will never force to use our proprietary clients to connect to Air VPN servers.

 

Kind regards