April 17, 2014 at 21:12OpenVPN successfully compromised through Heartbleed
The passion for the recently discovered Heatbleed vulnerability in OpenSSL does not subside. Yesterday, a message appeared on news.ycombinator.com that researchers were able to make several successful attacks on the OpenVPN server and compromise the private key that the server uses to decrypt the traffic sent by the client.
OpenVPN developers have previously warned users that the product uses the OpenSSL library and is vulnerable to this attack. But until yesterday there was no public information that the attack could indeed be successfully implemented. Researchers have demonstrated the ability to fake a remote server through the received private key, as well as decrypt with it the data passing between the real VPN server and the user himself.
The following test server configuration was used to conduct the attack: Ubuntu 12.04 OS (virtualization via KVM) OpenVPN 2.2.1 and OpenSSL 1.0.1-4ubuntu5.11.
However, it should be clarified that such an attack will not work against sessions with the TLS authentication option turned on, since in this case a separate private key is used to encrypt traffic.
We have successfully extracted private key material multiple times from an OpenVPN server by exploiting the Heartbleed Bug. The material we found was sufficient for us to recreate the private key and impersonate the server.
As you may know, OpenVPN has an SSL / TLS mode where certificates are used for authentication. OpenVPN multiplexes the SSL / TLS session used for authentication and key exchange with the actual encrypted tunnel data stream. The default TLS library for OpenVPN is OpenSSL.
OpenVPN developers have previously warned users that the product uses the OpenSSL library and is vulnerable to this attack. But until yesterday there was no public information that the attack could indeed be successfully implemented. Researchers have demonstrated the ability to fake a remote server through the received private key, as well as decrypt with it the data passing between the real VPN server and the user himself.
The following test server configuration was used to conduct the attack: Ubuntu 12.04 OS (virtualization via KVM) OpenVPN 2.2.1 and OpenSSL 1.0.1-4ubuntu5.11.
However, it should be clarified that such an attack will not work against sessions with the TLS authentication option turned on, since in this case a separate private key is used to encrypt traffic.
The attack vector that is present on the Access Server with the vulnerable OpenSSL libraries is not present on the Connect Clients, so the risk is minimal. Only the server that your client connects to could possibly exploit this vulnerability, and even then it is unlikely because we use Perfect Forward Security and TLS-auth on top of the SSL connection. The security of the data channel itself is not particularly at risk, only the web services on the server themselves are. And even then, since we use a privilege separation model, the web services run in a completely different process than the OpenVPN daemons handling the data connections, and therefore the private keys for your OpenVPN connections are not likely to be at any risk. Even so, we don't want to take chances and are going to release 2.0.7 soon,