TLS "Lucky 13" Attack

[JamesDean 10]

Is AirVPN vulnerable to any of this?

http://nakedsecurity.sophos.com/2013/02/07/boffins-crack-https-encryptionin-lucky-thirteen-attack/

 

[Staff 9972]

Is AirVPN vulnerable to any of this?

http://nakedsecurity.sophos.com/2013/02/07/boffins-crack-https-encryptionin-lucky-thirteen-attack/

JD

Hello!

The attack is ineffective against OpenVPN for various reasons:

- the attack is faster with DTLS, which is not used by OpenVPN

- in absence of DTLS, the attacker needs to send the same plaintext secret on thousands of different connections to the same server; in order to do so, aid of cookies, javascript injection and usage of a browser by the victim is mandatory, all requisites which are not met by OpenVPN

- the attack in absence of DTLS requires a considerable time, superior to the the TLS keys re-negotiation OpenVPN time (60 minutes by default, and you can also lower it on the client side)

- if an adversary has the power to inject forged packets in an OpenVPN connection, and even if the attacker were able to pass the OpenVPN HMAC verification, tunnel authentication renegotiation is started again by OpenVPN

It is relevant that the researchers who invented the attack (a variant of a previous, well-known attack to which OpenVPN is immune) did not cite OpenVPN in their paper, their attack was based, in absence of DTLS, essentially against https, because without cookies and javascript injections it is practically impossible to perform a successful attack.

Of course we will be following closely the developments, in case the attack is enhanced.

About our https website, using RC4 (fully supported by our web server) greatly mitigates the risks, and anyway you can connect to our website via TOR or via OpenVPN to stay absolutely safe.

References;

http://www.imperialviolet.org/2013/02/04/luckythirteen.html

Kind regards

[skxBMrYsxlli 9]

Is AirVPN vulnerable to any of this?

http://nakedsecurity.sophos.com/2013/02/07/boffins-crack-https-encryptionin-lucky-thirteen-attack/

JD

Hello!

The attack is ineffective against OpenVPN for various reasons:

- the attack is faster with DTLS, which is not used by OpenVPN

- in absence of DTLS, the attacker needs to send the same plaintext secret on thousands of different connections to the same server; in order to do so, aid of cookies, javascript injection and usage of a browser by the victim is mandatory, all requisites which are not met by OpenVPN

- the attack in absence of DTLS requires a considerable time, superior to the the TLS keys re-negotiation OpenVPN time (60 minutes by default, and you can also lower it on the client side)

- if an adversary has the power to inject forged packets in an OpenVPN connection, and even if the attacker were able to pass the OpenVPN HMAC verification, tunnel authentication renegotiation is started again by OpenVPN

It is relevant that the researchers who invented the attack (a variant of a previous, well-known attack to which OpenVPN is immune) did not cite OpenVPN in their paper, their attack was based, in absence of DTLS, essentially against https, because without cookies and javascript injections it is practically impossible to perform a successful attack.

Of course we will be following closely the developments, in case the attack is enhanced.

About our https website, using RC4 (fully supported by our web server) greatly mitigates the risks, and anyway you can connect to our website via TOR or via OpenVPN to stay absolutely safe.

References;

http://www.imperialviolet.org/2013/02/04/luckythirteen.html

Kind regards

It would still make a lot of sense to switch to or at least support AES-GCM to make the attack or any related future attack completely infeasible. Consider this a vote in favour.

(Now that Firefox should be getting support momentarily, it would be nice to see this on the web server, too. IE (or, rather, Windows schannel) appears to contain support as well. Chrome continues to use Windows schannel for its crypto—unknown whether it can use AES-GCM.)

[Wolf666 17]

I vote for AES-GCM support, I have a firewall/router running pfSense 2.2 and hardware with AES-NI support, VPN traffic would have a great benefit.

 

 

Sent from my iPad using Tapatalk

[zhang888 1066]

Hi Wolf666,

Wow, that is almost a 2 years old bump...

AES-GCM is still a milestone for OpenVPN 2.4.x, and it wasn't yet confirmed by them when (and if) they are planning to implement it...

https://community.openvpn.net/openvpn/ticket/301

 

So unless it will be supported there, there is not much Air can do in this matter :/

 

OpenVPN-NL supports GCM for awhile ago, I think since the last year or so.

https://openvpn.fox-it.com/

As well as some 3d party hacks:

https://github.com/syzzer/openvpn/tree/aead-cipher-modes5

 

But that's a custom patched version that is not supported by OpenVPN itself. I don't see other providers jump on it as well at this moment.

 

[Wolf666 17]

Thanks zhang888,

I hope OpenVPN will implement soon, hardware is ready and cheap.

 

 

Sent from my iPad using Tapatalk