Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common.
Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading.
(1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.
It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.
You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do).
This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.
Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.
I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.
OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option.
(Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)
While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).
CVE-2014-0224 is the only one that really impacts OpenVPN (No DTLS nor SSL_RELEASE_BUFFERS etc) and as others have said, if you are using OpenVPN chances are you are making use of TLS-AUTH which helps mitigate MITM issues to a reasonable degree. Furthermore, both sides apparently need to be vulnerable. So if you have little control over the clients, updating the server seems to be adequate to address this specific bug.
If I'm understanding the CVE correctly, it has nothing to do with the browser. It's when it's on the Server, an attacker could just make OpenSSL think their "browser" doesn't support all of the good algo's and eventually cycle through it's available algo's until a relatively insecure one is decided upon (like the relatively weak CBC algo's).
So, it is a potential threat to servers since most web server are *nix based and most of those will have the default of OpenSSL installed.
However, I seem to recall this always being a possible attack vector, in any SSL/TLS library due to how browsers/servers have always negotiated which algo to use based on which are commonly supported and the strongest available... so ... nothing new?
With any OpenSSL client talking to an OpenSSL 1.0.1
server, an attacker can inject CCS messages to fixate the
bad keys at both ends but the Finished hashes will still
line up. So it's possible for the attacker to decrypt
and/or hijack the connection completely.
Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading.
(1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.