On 2009.11.08 at 00:17:38 +0100, David Sommerseth wrote: > > Well said! Thank you for emphasising this. In my earlier posts, I > never intended to suggest that this was a work around, just to be clear > about that. But --tls-auth is now, how I see it, the only way currently > available "immediately" (vs. waiting for openssl to be widely available > on all distros) which can make you safer against the current SSL/TLS flaw.
Can anybody explain, how the "current SSL/TLS flaw" can be used to exploit OpenVPN. As far as I can understand this flaw is ability to upgrade secure connection from non-authenticated to authenticated transparently to application layer. If then application applies security context of the upgraded connection retroactively to the data send by non-authenticated client before upgrading, exploit is possible. This is typical behavoir of HTTP servers, which allows https connection without client authentication, and then request renegotiation based on URL send by encrypted, but not-authenticated connection, and if proper client certificate is supplied - perform request send before authentication. Moreover, attacker cannot even read result of this request, because it is send over upgraded coonection. So, it is not really applicable to any connection-based protocols which maintain state. Only stateless HTTPS is vulnerable. I cannot imagine even IMAP exploit, because IMAP severely limits set of commands, available in the pre-auth state. But OpenVPN uses TLS for authentication and key negotiation only. So, non-authenticated man-in-the-middle attacker cannot send any commands which would be executed after attacker hand connection over to legitimate client.
