New FREAK-like TLS Vulnerability: Logjam

[koloc-1458-261 0]

FYI: Severe FREAK-like attack against the TLS Protocol and Diffie-Hellman.

 

https://weakdh.org

 

Infosecurity: http://www.infosecurity-magazine.com/news/freaklike-logjam-attack-undermines/

[zhang888 1065]

This requires a vulnerable browser with shorter keys fallback option.

Air uses 4096 DH keys which is mandatory, hence this vulnerability doesn't affect the users of Air.

 

Let's wait for an official comment from Staff.

[Staff 9751]

Hi zhang888 and everybody,

 

disclaimer: this message is written by only one person of the staff, while other persons are still investigating.

 

We confirm that:

- in VPN servers we use Diffie-Hellman 4096-bit keys

- in VPN servers we do not use the same prime numbers used by millions of web sites

- our web site does not support DHE_EXPORT

 

That said, we are still investigating whether a TLS downgrade on the Control Channel is possible and, even if it was, how to affect DHE to force one of the sides to a DHE_EXPORT downgrade up to 512 bit.

 

References which we have started from:

 

Theory:

https://weakdh.org/imperfect-forward-secrecy.pdf

 

Practice:

https://weakdh.org/logjam.html

 

At the moment, we operate from a very conservative/paranoid approach so we are not ruling out 100% anything, but we can at the moment state that:

 

- web site is totally secure on server side

 

About OpenVPN in our setup:

- Attack I is obviously not possible, since it requires weak DH 512-bit primes in the first place

- Attack II (and therefore Attack III) appears infeasible, for different premises which are not met:

"The server, in this case, only needs to support DHE_EXPORT cipher suites or use 512-bit parameters in non-export DHE ciphers. The client must be using the TLS False Start extension; that is, the client sends application data before receiving the server's Finished message in the TLS handshake."

 

The question is whether it's possible to think about a mutant, specific attack form explicitly aimed to OpenVPN Control Channel to affect DH keys for Data Channel encryption. We will keep you updated of course.

 

We are focusing on OpenVPN because even if you use it over SSH or stunnel, TLS+DHE downgrades on them appear to be not essential since your main "defensive" layer remains on the underlying OpenVPN.

 

Kind regards

[skxBMrYsxlli 9]

Hi zhang888 and everybody,

 

disclaimer: this message is written by only one person of the staff, while other persons are still investigating.

 

We confirm that:

- in VPN servers we use Diffie-Hellman 4096-bit keys

- in VPN servers we do not use the same prime numbers used by millions of web sites

- our web site does not support DHE_EXPORT

 

That said, we are still investigating whether a TLS downgrade on the Control Channel is possible and, even if it was, how to affect DHE to force one of the sides to a DHE_EXPORT downgrade up to 512 bit.

 

References which we have started from:

 

Theory:

https://weakdh.org/imperfect-forward-secrecy.pdf

 

Practice:

https://weakdh.org/logjam.html

 

At the moment, we operate from a very conservative/paranoid approach so we are not ruling out 100% anything, but we can at the moment state that:

 

- web site is totally secure on server side

 

About OpenVPN in our setup:

- Attack I is obviously not possible, since it requires weak DH 512-bit primes in the first place

- Attack II (and therefore Attack III) appears infeasible, for different premises which are not met:

"The server, in this case, only needs to support DHE_EXPORT cipher suites or use 512-bit parameters in non-export DHE ciphers. The client must be using the TLS False Start extension; that is, the client sends application data before receiving the server's Finished message in the TLS handshake."

 

The question is whether it's possible to think about a mutant, specific attack form explicitly aimed to OpenVPN Control Channel to affect DH keys for Data Channel encryption. We will keep you updated of course.

 

We are focusing on OpenVPN because even if you use it over SSH or stunnel, TLS+DHE downgrades on them appear to be not essential since your main "defensive" layer remains on the underlying OpenVPN.

 

Kind regards

Much appreciated. I haven't had a chance to look into whether current OpenVPN releases support it, but the best advice available seems to be to move on to ECDHE to prevent as-yet-undiscovered attacks while providing PFS / FS (forward security).

 

Is AirVPN able to provide ECDHE support at this time?

 

Thanks!

[Staff 9751]

 

Much appreciated. I haven't had a chance to look into whether current OpenVPN releases support it, but the best advice available seems to be to move on to ECDHE to prevent as-yet-undiscovered attacks while providing PFS / FS (forward security).

 

Is AirVPN able to provide ECDHE support at this time?

 

Thanks!

 

Hello!

 

Not immediately, some radical changes are needed in our setup:

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

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

 

That would be optional not to risk to break compatibility with a potentially massive percentage of our customers who do not run OpenVPN supporting/patched for ECDHE.

 

However, at the moment this would seem unnecessary for logjam, because we use our DH group with 4096 bit prime:

http://sourceforge.net/p/openvpn/mailman/message/34132515

 

We are hesitant with Elliptic Curves Cryptography, because we would start to use curves based on parameters recommended by NIST, which are the curves "created" by Solinas (NSA).

 

More details on our hesitations:

https://airvpn.org/topic/14086-about-updating-the-hash-message-authentication-code/?do=findComment&comment=26950

 

Therefore: since logjam does not seem to affect our service, we can evaluate to postpone ECC support to OpenVPN 2.4. When it will be released, we could count on generic OpenVPN ECC support (i.e. with no patches to apply), in any case after our doubts are solved, Alternatively, we could add optional ECDHE support before OpenVPN 2.4 release (keeping good old discrete log cryptography available for compatibility) but only when we can trust NSA curves (or when OpenSSL does not use NSA curves group).

 

Kind regards

[zhang888 1065]

Most promising looking eliptic curves would be some variation of curve25519. In particular a proposal for supporting signed keys has
been made: http://ed25519.cr.yp.to/software.html

 

Having said that, it's great to see that Air was among handful of public providers that chose to shift to 4096 DH, although a little late (2014),

but better late than never. At least Logjam and EXPORT_NSA cipher attacks are no longer applicable

[Staff 9751]

Most promising looking eliptic curves would be some variation of curve25519. In particular a proposal for supporting signed keys has

been made: http://ed25519.cr.yp.to/software.html

 

Hello!

 

Exactly, starting from Bernstein and Lange criticism and proposals, there appear to be plenty of good options.

 

 

Having said that, it's great to see that Air was among handful of public providers that chose to shift to 4096 DH, although a little late (2014),

but better late than never.

 

Thanks! But between 2010 and 2014 we anyway used 2048 bit DH, we never implemented 1024 DH in the public service.

 

Kind regards