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…
This should be interesting for OpenVPN.
http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartblee...
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.