Re: [Openvpn-users] New TLS MiM attack (Lucky 13)

[David S. <ope...@to...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/02/13 16:50, Mike Tancsa wrote:
> Not sure how many OpenVPN users this will impact
> 
> 
> http://www.isg.rhul.ac.uk/tls/index.html

Since nobody else haven't raised their voices, I'll give a little
heads-up.  This issue have been discussed among people in the
development team before it was announced publicly.  The information
embargo was released when it got public on Monday, with a relatively
co-ordinated update release among most of the SSL libraries.

First of all let me state that I am not a cryptologist, so I'm have
limited understanding of the deeper details.  But I'm doing my best to
summarize this in layman's terms, hopefully without sacrificing or
tweaking too much of the real truth.

Also remember that OpenVPN's security is fully dependent on the SSL
library it uses (from v2.3.0, that means either OpenSSL or PolarSSL)
in regards to SSL/TLS issues.  But!  There are several features in the
SSL libraries which OpenVPN doesn't make use of, which in many cases
makes OpenVPN avoid some of the security issues found in SSL
libraries.  OpenVPN can also add additional layers, which is not
directly SSL/TLS wire-protocol related which makes it harder to break
OpenVPN.

- From the discussion among the developers, it was not found anything
particular which could weakens OpenVPN's security.  To my
understanding that means that if this attack was attempted on OpenVPN,
OpenVPN would generally reject these packets and start a new tunnel
negotiation.  In addition, if --tls-auth is added to your
configuration, the additional HMAC authentication would most likely
also fail, the server or client would just drop those packets before
parsing them further.

The issue found is also closely related to DTLS, which is a protocol
OpenVPN does not make use of.  OpenVPN implements its own solution to
gain the same features as DTLS provides (basically possibility to have
TLS over unreliable/stateless connections such as UDP).  This also
means that OpenVPN is more likely to steer out of the way with DTLS
related issues.

The issue itself, again how I understands it, is related to timing and
padding.  Very simply explained, by providing a wrong padding and
based on the response time of those packets it was possible to break
the connection in a way where it might leak enough information to
decrypt the encrypted data.

I know PolarSSL implemented a technique which would provide almost the
same response time regardless of the padding from the client, which
makes it close to impossible to use this timing attack vector.  Which
solution OpenSSL chose, I am not aware of currently.  But we are
concerned that their implementation broke something [1], unless
OpenVPN have implemented OpenSSL wrongly.  This is being investigated now.


[1] <https://bugs.gentoo.org/show_bug.cgi?id=455810>


- -- 
kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlETmhIACgkQDC186MBRfrp9wACfSryf/KYIaRMCJhCWnpLIj4kP
jPQAnRqtWbtKk9fkzP2uWOkhLXvt55V9
=QRun
-----END PGP SIGNATURE-----