How are VPN providers handling the Heartbleed crisis? -

How are VPN providers handling the Heartbleed crisis?

Douglas Crawford

Douglas Crawford

April 9, 2014

As we reported yesterday, security researchers have discovered a major flaw in how OpenSSL encryption is implemented on a vast number of the internet’s websites (at least over 66 percent of all websites). Unfortunately there is little that end-users can do about this, except perhaps try to avoid using the internet in sensitive ways for a few days, and hassling commonly used secure websites to explain what they are doing about the problem.

Because VPN is often used (in fact for many it is its primary purpose) to protect sensitive data and provide privacy, it is particularly important that VPN providers address any vulnerability to Heartbleed ASAP. Unfortunately, the bug has existed for around two years, and a successful attack would leave no trace, so it is impossible to know if a website or VPN service has been compromised.

It should be noted that services which use ephemeral keys (i.e. Perfect Forward Secrecy) are largely immune to any possible attack.

Here then is our roundup of what we know VPN providers have said about Heartbleed, and what they are doing about it, and we shall update this article as we find out more news. We should note that many websites have stayed eerily quiet over the issue, which is quite alarming, and will contact as many of them as we can to discover their responses (if any).


Not a provider as such, but until providers’ fix the vulnerability on their servers and custom software, it is probably a good idea to use newly updated generic OpenVPN client for Windows, or Tunnelblick for Mac.

‘OpenVPN has been updated to close the Heartbleed vulnerability

OpenVPN 2.3.2 I003 (the version that was current until today) contains a vulnerable version of OpenSSL built into the Windows client. It has been updated to version 2.3.2 I004, which closes this vulnerability.

Additionally, OpenVPN 2.3.3 is supposed to come out on April 10th. It will contain options so that clients and servers will deny connections from vulnerable builds of OpenVPN.

Here is a link to the official OpenVPN I004 client:

If you are using Linux/BSD, you’ll want to update your version of OpenSSL to current, as it is installed separately as a dependency.


Tunnelblick (the open-source OpenVPN client for Apple OSX) was updated today to close the vulnerability. The new client can be downloaded here:

Edit2: The Viscosity Client now has beta versions for OSX and Windows that also close the vulnerability.

Windows Version:

Mac Version:

As of this writing, OpenVPN Connect for Android and OpenVPN Connect for iOS have not been updated.’ Source.


Emergency Patching Applied To All Servers To Combat Heartbleed

VikingVPN is currently doing emergency patching to all VPN servers in order to close a new vulnerability in OpenSSL named Heartbleed. This is a particularly nasty bug in OpenSSL 1.0.1 that would allow an attacker to invisibly read small sections of secure data in memory due to a faulty software pointer.

What we are doing:

Emergency patching OpenSSL on all VPN servers to close the security hole. We are also updating the hardened server that generates customer keys and certs.

How this impacts our users:

Because we use ephemeral keys, and our website does not use OpenSSL, and our root CA for the VPN was not exposed by this vulnerability, the impact to the user is far less serious than it could have been. It is not possible through this vulnerability that a security key could have been exposed server-side, because the OpenVPN server build we use does not utilize a vulnerable version of OpenSSL (it uses the 1.0.0 fork, not the 1.0.1 fork).

Because we use the tls-auth directive for the “HMAC Firewall” setting in OpenVPN, and we do not allow it to be disabled, there is no risk of a client side data breach.

What user action should be taken:

– If you have any apps that rely on OpenSSL, you’ll want to upgrade to the latest version of OpenSSL as soon as possible. This vulnerability is going to get ugly fast, because it is very clear how the exploit works, and it is only a matter of time before an app is written specifically to exploit it.

– Although it is likely entirely unnecessary, the best step that our users can take right now would be to get a new set of keys and certs from our website. You can do this by signing in to the website, and visiting the profiles area. There you can generate a new set of config files that will contain entirely new keys and certs, and it will revoke all of the existing keys and certs for your account.

– A patch for the Windows OpenVPN Client has been issued that closes this vulnerability. You can download and install the latest version (2.3.2 I004) here. OpenVPN 2.3.3 is going to be released Thursday April 10th, which will contain the same fix, plus additional security enhancements and features.

– If you are using a non-windows client, OpenVPN does not have a built in OpenSSL library. You will just need to update the OpenSSL build to current via your repositories.’ Source, SSL Report.


Heartbleed OpenSSL bug


A serious vulnerability in the popular OpenSSL cryptographic software library was disclosed 30 hours ago. In short it allows (among other things) anyone on the Internet to extract the private keys used for encrypting traffic and identifying service providers to their users. A more complete description can be read on This affects a lot of different services including web, email, instant messaging and OpenVPN (which Mullvad uses).

As of a few hours ago all our servers have been patched and are no longer vulnerable. We are also releasing a new Mullvad client for all supported operating systems (OSX, Windows, Linux) and an updated configuration package if you use OpenVPN without the Mullvad client.

On the server side OpenSSL has been upgraded, and since we could not rule out a leak of one or all of our servers’ private keys we have revoked all of them and generated new ones. The new client includes a Certificate Revocation List with all revoked certificates and a patched version of OpenSSL (for Windows and OSX users). Our Linux client doesn’t bundle OpenSSL and relies on the user’s Linux distribution.

To protect yourself against a so called man-in-the-middle attack when connecting to Mullvad you should upgrade to the new client immediately. If you use OpenVPN without using our client you should download a new configuration package from our website.

Source, Heatbleed test.


After a deeper analysis we would like to inform you about problems, solutions, what we did and what you need to do, in compliance with our transparency policy. The OpenSSL 1.0.1a–>f vulnerability is huge, but several factors in our infrastructure design made the menace a minor threat, without any potentially catastrophic consequence.

  • some of our OpenVPN servers used a vulnerable OpenSSL version. They have been all updated and upgraded between 3 PM and 6 PM 08-Apr-14 CET+1. The non-updated VPN servers running branches of OpenSSL like 0.9.8 were not and are not vulnerable. Assuming that an attacker could steal your user.key during the handshake on those servers, the worst damage is that he/she will connect with your account in the future (see below for a solution to this problem). He/she will not be able to decrypt your OpenVPN Data Channel. Various factors help mitigate the problem even on those vulnerable VPN servers: the attacker could not perform an attack through the exit-IP address (he/she should have known the entry-IP) and Perfect Forward Secrecy does not allow the attacker to decrypt your data
  • the primary frontend (the web site you normally visit) used a vulnerable OpenSSL version which has been upgraded at 3 PM 08-Apr-14 to a non-vulnerable version. All sessions were reset. The vulnerability allowed an attacker to dump a memory portion of the server which could disclose information useful to exploit future access of those users using browsers or web clients not supporting DHE or ECDHE: Internet Explorer 6, Internet Explorer 8, YandexBot 3, or browsers manually forced NOT to use Perfect Forward Secrecy.
  • the backend servers and other vital parts of the infrastructure were not and are not vulnerable, since they were NEVER running a vulnerable OpenSSL version

What we have already done:

  • we replaced on every part of the infrastructure the vulnerable OpenSSL versions (if any) with non-vulnerable ones between 3 PM and 6 PM 08-Apr-14 CET+1
  • we changed in advance all administrative accounts passwords (this was not strictly necessary, but it has been performed anyway)
  • we updated the internal SSL certificates
  • we reset connections of clients connected to VPN servers running OpenSSL vulnerable version and rebooted the server to make sure that no old dynamically linked SSL version was still used by OpenVPN
  • we performed attacks against our servers, even with the help of independent attackers as peer review, to check that the vulnerability has been resolved
  • we have ordered the revocation of the frontend web server previous SSL certificate (this will go into effect in 72 hours according to authority policy)
  • UPDATE 11.15 PM 08-Apr-14 CET+1 we changed the SSL certificate and private key of our frontend servers
  • UPDATE 12.40 AM 09-Apr-14 CET+1 we released a new package for Windows with OpenVPN using non-vulnerable OpenSSL

What we will additionally do:

  • we’re going to add the option to generate new user.key from the client side, with no more need of our manual intervention, just in case someone wishes to use our service for free with your account
  • UPDATE 1.50 PM 9-Apr-14 CET+1 We are planning a major change in the system with new RSA and DH keys, new certificates and more. The operation is complex and will cause interruptions to the service. You will need to re-download configuration files, certificates and keys, re-configure DD-WRT/Tomato/pfSense etc. so we are planning it with care. A discussion about it is still ongoing and will go on probably for hours, so we can’t provide more details. Please stay tuned.

What YOU need to do:

  • change your account password and your API key (if you used our API) and do it as soon as possible especially if you use Internet Explorer 6, Internet Explorer 8 or YandexBot 3 or any other browser that you specifically configured NOT to use TLS with DHE-ECDHE in any way to log in our web site. On this occasion, please consider to drop once and for all Internet Explorer 6 and 8 and prefer browsers supporting PFS
  • change your user.key when this option will be available
  • Windows users only download and install new package with OpenVPN using non-vulnerable OpenSSL Allow Air client to upgrade OpenVPN version if required
  • OS X Tunnelblick users only download and upgrade to new Tunnelblick with non-vulnerable OpenSSL…k/wiki/RlsNotes
  • Remain in touch because we have planned modifications to the service which will require your attention and intervention.

Source, SSL Report.

Private Internet Access

An (alleged) PIA staff member issued the following statement as forum post,

‘Our website was never vulnerable to Heartbleed. However, as a precautionary step, we’ve already patched all our VPN servers to ensure your security.’ Source.

Unsurprisingly this has failed to satisfy many commentators (see debate here), but the Qualys SSL Report for the PIA website finds that ‘This server is not vulnerable to the Heartbleed attack’ (although it only scores a ‘B’ grade overall, and does not use Perfect Forward Secrecy.

Update: A bit late, but PIA have now responded publicly:

April 10, 2014

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.

Our Website
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.


The heartbleed bug was introduced in OpenSSL 1.0.1 and is present in

  • 1.0.1
  • 1.0.1a
  • 1.0.1b
  • 1.0.1c
  • 1.0.1d
  • 1.0.1e
  • 1.0.1f
Our servers all use same repository for installs and the openssl version we use is not one of the affected ones. However we’re preparing a upgrade of the newly released OpenSSL 1.0.0g for Chameleon.
We do use ephemeral keys and our communication is safe from the RSA attacks.
Our web server also passes a simple online test, I’ve attached a screenshot [which we received, ]
We’re brainstorming with the smart bunch around here with a further security upgrade that will add an extra layer of security to the customers.
I’ll let you know more details as we investigate and move further.
Update 10 April: VPNArea have contacted us to say that ‘we’ve now released new VPNArea Chameleon version with latest openvpn source code implemented’.



Websites new SSL certificate is in place

Wednesday, April 9, 2014

The new SSL certificate is now in place and the old one has been revoked.

LiquidVPN VPN Servers have been patched for heartbleed bugWednesday, April 9, 2014

All of our OpenVPN servers have been patched and new private keys generated. Software update has been published to update Liquid Viscosity and are in beta. We recommend you update OpenVPN software if you are using it.


A critical bug in OpenSSL – known as the Heartbleed bug – has been discovered which affects web, email, instant messaging and VPN services.

Only customers connecting using OpenVPN are affected – L2TP/IPsec users do not need to do anything. Hopefully nobody is still using PPTP for private communications as it is only useful for stuff like unblocking websites.

Our website was NEVER vulnerable because it was running an unaffected version of OpenSSL (0.9.8g). We’ve now updated OpenSSL there anyway.

Initially we thought that no VPN servers were vulnerable as most were using an older unaffected version of OpenSSL. Unfortunately we did find some servers that were vulnerable so we updated all servers on April 8th as soon as we find out about the bug. All OpenVPN sessions were reset on 8th April as we upgraded.

Since we use ephemeral session keys the data sent and received over the VPN (aka your OpenVPN Data Channel) should be safe from this attack. The worst that could have happened is your VPN username and password were compromised which would allow someone else to use your account, so we suggest that you reset your VPN password just to be safe.

We cannot be sure that our server keys were safe from attack so we will be generating new keys and client configs to be on the safe side. Once new client configs are released we recommend everyone to download them to prevent possible Man-In-The-Middle (MITM) attacks.

Updated versions of OpenVPN for Windows and Tunnelblick for Mac OS X have now been released and we recommend everyone upgrade immediately. Linux users need to upgrade to the latest version of OpenSSL as soon as possible. We’re working on updated blackVPN Easy Installer versions for Windows and Tunnelblick and these will be released shortly.


TorGuard VPN Audit Results: HeartBleed SSL Bug

09/04/14 12:48 PM

After TorGuard’s engineering team carefully reviewed our network, software and website infrastructure, we would like to publicly update our clients on the results of these findings. While the threats posed by the OpenSSL 1.0.1a HeartBleed vulnerability are wide reaching and potentially very serious, our team can confidently say this development will have no impact on the security of TorGuard or its services. This post may be updated in the coming days as we continue to analyze and conduct our own private testing across our network.

What is the HeartBleed Bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

TorGuard responded immediately to these findings by conducting a system wide audit of all servers. Please review the latest audit findings below: Website Infrastructure:

The front end website, member’s area, and back end administration systems are not affected by this vulnerability. Clients can rest assured that no possible exploit of this nature could have taken place on’s website during the prior months while this bug was in the wild. Even so, all administration passwords are cycled on a regular basis and we encourage clients to do the same as a precautionary measure. It is also important to make sure that your email provider, IM software, or any other secure login platform used is up to date on this issue.

The server and client email systems are also not affected by this vulnerability and were not vulnerable in the months prior.

TorGuard OpenVPN Software

TorGuard lite (OpenVPN) – TG’s popular “lite” OpenVPN app for Windows, Mac and Linux is not affected by this bug as it uses a previous version of OpenSSL (0.9.8) which does not have heartbleed enabled. If you are using TorGuard lite you do not need to take any action in updating your client software.

TorGuard Pro (Viscosity) – TorGuard has already pushed a software update for both Mac and Windows users that will update the VPN client to our latest patched version. Users will be prompted by the software to update to this latest version, just select the “update now” button that pops up when starting the VPN software. Customers can also now download the patched updated for Pro (Viscosity) software directly for Windows here and Mac here. Those who still remain using older version will be promoted daily to upgrade.

TorGuard Android App – The TorGuard android app uses OpenSSL version 1.0.0e which is NOT affected by this bug. No update of TorGuard’s Android VPN client is needed.

OpenVPN GUI – If you are using a stand along version of OpenVPN GUI please take action and to update your client to the latest version of OpenVPN (2.3.3) which has just been released here.

TunnelBlick GUI – If you are a MAC user running TunnelBlick, please update to the latest version here.

TorGuard VPN Server Network

After an extensive and complete audit of our entire VPN server network, we would like to report that only 5% of our server clusters were found to be using the compromised version of OpenSSL. These locations were strictly limited to our USA data centers and are being updated between the hours of 11am GMT – 1pm GMT. New server configurations for these locations have automatically been pushed to all TorGuard software (lite, Pro, Android), however if you are using a stand-alone OpenVPN GUI software client please be sure to download our latest config files here. If you are using TorGuard’s PFsense, iOS, or DDWRT scripts it is important for you to visit the downloads page and pickup the latest updated version.

Serious vulnerabilities such as this serve as a constant reminder that we must be forever vigilant in preserving the integrity of security services. TorGuard’s staff is relentlessly committed to preserving these values and will continue to deliver professional privacy solutions for our clients far into the future.

Source, Heartbleed test.

Douglas Crawford

I am a freelance writer, technology enthusiast, and lover of life who enjoys spinning words and sharing knowledge for a living. You can now follow me on Twitter - @douglasjcrawf.

4 responses to “How are VPN providers handling the Heartbleed crisis?

  1. We’ve also responded publicly to the Heartbleed bug on Reddit:

    Our website was NEVER vulnerable because it was running an unaffected version of OpenSSL (0.9.8g). We’ve now updated OpenSSL there anyway.

    Initially we thought that no VPN servers were vulnerable as most were using an older unaffected version of OpenSSL. Unfortunately we did find some servers that were vulnerable so we updated all servers on April 8th as soon as we find out about the bug. All OpenVPN sessions were reset on 8th April as we upgraded.

    1. Hi blackVPN,

      Thanks. We have added your response to the list, and appreciate your contacting us.

  2. Thanks Douglas, a really good summary.

    What is the impact of heartbleed likely to be on stored data. Is all data retained which was encrypted using openvpn PIA or similar services now accessible.

    1. Hi Alex,

      If a provider did not use ephemeral keys (PFS) for its VPN connection, and if an adversary ( the NSA ) had collected and retained all encrypted data from that service, then yes, they could use the bug to obtain the encryption keys and decrypt all the stored data (as I understand the situation). This is the sort of reason Bruce Schneider described the bug as ‘catastrophic… On the scale of 1 to 10, this is an 11’. Of course, some people are beginning to ask if the NSA knew about the bug all along (watch out for an article on this)…

Leave a Reply

Your email address will not be published. Required fields are marked *

Exclusive Offer
Get NordVPN for only
Get NordVPN for only