Heartbleed: Post Mortem
At Private Internet Access, we consider our customers’ privacy and security to be our highest priority. That is our business. That is our expertise. We wanted to take a brief break from our ongoing research and development to discuss a few of the decisions we made to prepare for attacks like Heartbleed, as well as how we reacted to Heartbleed itself, post public disclosure.
As we stated earlier on our forum and social networks, our website was not and continues to not be vulnerable to the Heartbleed bug. This is the case, because our hardware load balancers are not running the vulnerable OpenSSL implementation. However, we still went ahead and revoked, re-keyed and rotated our certificates as a precautionary measure.
Our VPN Servers
All of our VPN gateways were patched within 4 hours (UTC 23:17:15 on Apr 7 2014) of the public disclosure of Heartbleed (UTC 19:00:00 on Apr 7 2014). We moved from OpenSSL 1.0.1f to the non-exploitable version 1.0.1g. In terms of our keys, the original researcher who discovered Heartbleed, Neel Mehta, says that private keys are safe, and we agree with his conclusion.
Additionally, the keys are used for the DHE/ECDHE key exchange, which means posession of the certificate doesn’t expose the actual keys used to encrypt your data. What this means is that assuming someone has a 0day exploit of any kind that compromises our certificates, they would still not be able to decrypt and read your network data.
It’s also worth noting that, after the Heartbleed disclosure, a number of POCs (proof of concepts) have been made available to the public. Those scripts only attacked TLS running over HTTP (HTTPS) and don’t work with OpenVPN’s custom protocol over which it runs TLS, which is far more complex than running TLS over TCP like HTTPS does. As far as we know, there were no exploits in the wild for OpenVPN’s custom protocol implementation of TLS, especially not in the window from the announcement of the exploit to the fix by our team.
Our VPN Clients
Our clients do not require any updates, because the application has preventive measures to protect against connecting to a malicious server. Additionally, assuming that for a different reason a VPN client could connect to a malicious VPN server, the fact that the VPN client is vulnerable to heartbleed does not harm it in any additional way. Given that all modern operating systems we support through our client have memory protection that prevents a process from reading memory from a different process, the malicious server would only be able to read data that belongs to the OpenVPN client, that is, the data that the client is already sending to the server.
To be clear, even if for some reason your adversary was able to obtain your Private Internet Access login credentials, they still would not be able to decrypt your data transfer.
Peace of Mind
Please rest assured that we’re constantly researching security to ensure the highest levels of privacy for our users. While no single website/service can guarantee 100% security, we assure you that we are second to none in striving to achieve said levels. However, in the event that we’re not perfect, we have many safeguards in place. Finally, if you are a security researcher and believe you have discovered an exploit, please participate in Private Internet Access WASP.
We will continue to monitor Heartbleed for any new revelations and update if necessary.