OpenVPN Security Advisories



Security researcher Ahamed Nafeez has presented a new attack vector which targets VPN tunnels which utilize compression, named VORACLE. The attack vector bears similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections.

It has been discovered that it is possible to gain information about an encrypted VPN tunnel's contents in very specific circumstances, if an attacker has the ability to capture the encrypted data packets while a certain type of data is transferred through the VPN tunnel. By that we mean that if a VPN user visits for example an unencrypted HTTP website through an encrypted VPN tunnel, and this information is being compressed and encrypted through the VPN tunnel, certain clues about the contents of this information can still be gathered if the encrypted packets can be captured and analysed, and data can be fed through the VPN tunnel by the attacker. To explain this better, following below is a simplified example. The example mentioned here is not the only possible attack against encryption combined with compression, and it is also very simplified, but it is useful to explain the principle behind attacks like VORACLE, CRIME and BEAST.

Let's say Alice has setup a login page. To check passwords entered there, Alice sends a message like "tell me if <the password entered> matches <secret password>" to Bob. This information between Alice and Bob is sent through an encrypted VPN tunnel that also uses compression. The more similar the <the password entered> is to <secret password> the better this message compresses. If the attacker Eve can ask Alice to verify passwords and can see the length of the encrypted VPN messages, she gets a pretty good idea how close her guesses are, since the encrypted messages get shorter when her guesses get better.

Without compression the length of the encrypted packets does not change, so Eve cannot gain any information from this. Strictly speaking the length changes if Eve's password length changes but that gives no additional information. The real world attacks are more complicated and need to take in account the specific circumstances (for example HTTPS or VPN) but they rely on the same principle as demonstrated in this simple example.


Due to the fact that exploiting such an attack is not trivial, we are not treating this situation as an emergency. For now, it is advised that users of the OpenVPN Access Server and the OpenVPN Connect Client software disable the use of compression. This effectively makes exploiting this vulnerability impossible. This can very easily be done on the OpenVPN Access Server by going to the admin web interface, and going to Advanced VPN. There you can disable compression. The client connection profiles may still provide an instruction to enable compression, but it will be disabled if the server denies the use of compression.

For open source OpenVPN users, we direct you to the community wiki article regarding VORACLE.


There are still discussions ongoing on how exactly in the open source OpenVPN project compression will be disabled, but for now in our commercial products we will be disabling compression by default in future releases of Access Server. We intend to make it so that when people update their OpenVPN Access Server, or install a fresh Access Server installation, the default setting will be that compression will be disabled. We will also be hiding and disabling the compression feature in later releases of OpenVPN Access Server and work on phasing it out entirely over time, as there is at this time simply no secure method of guaranteeing the security of the data in all situations while compression is enabled.

Our Private Tunnel cloud service had encryption switched off already, so is not affected by this issue.



For a short while now it's been known that there are some serious flaws called Meltdown and Spectre that are causing possible security problems for almost all computers. A solution for this, or at least most of the problems, has been created in the form of kernel patches and adjustments in the deepest levels of operating systems like Windows, Macintosh, and Linux, and so on. OpenVPN Access Server itself is only a user-space program and does not run in the kernel and therefore we as creators of the Access Server product do not create these patches. However, we can inform our users on how to get the necessary patches.


Our OpenVPN Access Server appliances have for roughly the past 3 years been based on Ubuntu 13, Ubuntu 14 LTS, and Ubuntu 16 LTS. It is important to figure out which operating system your Access Server runs on, and to then take appropriate action to update the operating system software to get the patches and to verify that they have been installed. For Ubuntu specifically there is a page that describes very well how to patch Ubuntu:

For users that run another operating system or an operating system that is no longer supported and updated by their maintainers, it is recommended to plan maintenance to set up a new installation and to migrate data and license keys (if applicable) to the new server setup, so that you can then enjoy updates for the operating system and get the necessary patches to mitigate the most problematic issues of Meltdown and Spectre. An alternative option is to perform an in-place dist-upgrade of the operating system, but success in this may vary and there is a chance the license keys may be invalidated in the process, requiring intervention from us to reissue your license keys for you. The safest course of action when your operating system is no longer supported is to set up a new system with a supported OS and contact us to get license keys migrated to the new system once things are setup and tested properly.

More information on the Spectre and Meltdown issues can be found here:

More information about a migration process and how to update Access Server itself is here:



In beginning of November of 2017, we had released a new version of OpenVPN Connect for Android with many security and functionality improvements. Shortly thereafter however we received reports from some users that making a connection was no longer possible. The error messages varied from "certificate verification failed" to "TCP EOF" network errors. We've traced this down to certificates being used by older implementations of OpenVPN open source servers that were using MD5 type signature hashes. These signatures are insecure and should not be used anymore.

It is important to note here that OpenVPN Access Server was not affected by this issue. We are talking here about open source implementations of OpenVPN that were using certificates signed with a hashing method called MD5 that has been determined to be broken and which should not be used anymore. Customers of our commercial OpenVPN Access Server offering did not suffer from these problems as we never used such a weak cipher and do not need to take action. This only really affects people using an open source OpenVPN implementation either set up themselves or part of a third-party embedded product like a router or VPN server product with some poor security settings.


We had temporarily added support for MD5 type signature hashes back into the OpenVPN Connect for Android app, which is available on the play store now. If you upgrade to this version then this particular problem should be resolved for you if you go into the setting and enable support for weak ciphers. Eventually though, support for this will disappear entirely. But the real problem, namely the use of MD5 hash certificates, is not resolved by this. It is strongly encouraged to use secure certificates instead of the flawed MD5 type certificates. It is absolutely not secure to use these older type of certificates and we cannot in good conscience continue to support such a poor level of security in our OpenVPN security product. Therefore official support for MD5 will be ending in May of 2018, and we may allow this some time more through the use of a special override in the settings of the client program. This gives our users time and motivation to migrate to a secure configuration using for example certificates signed with SHA256 type hash or better.

See FAQ item regarding MD5 support on Android app for more technical details on how to detect and resolve this problem.



A while ago an issue was discovered in the Network Time Protocol (NTP) daemon that we generally advise people to install on a server running OpenVPN Access Server on Ubuntu. The purpose of the package is to ensure that the time is always correct on the server. This is especially vital when you make use of the Google Authenticator functionality built into the Access Server, as it is time-dependent. On cloud based platforms and other virtualization systems it is not uncommon that time slowly drifts. NTP corrects this automatically.

The vulnerability found has been given designation CVE-2016-9310 and to put it simply, it allows an attacker to use the NTP server to attack other servers with bandwidth. The method is called traffic magnification and basically comes down to make a small request that results in a larger response to a specific target. Enough of these attacks could bring a server down (DoS). Other serious issues have also been found. You can read more about it in the pages linked to below. Fortunately for our users of the OpenVPN Access Server on AWS, our default security groups settings that come with the appliance do not provide access to the NTP daemon at all. So unless these were changed and access was granted to the NTP service port, this flaw cannot be exploited remotely with our Amazon AWS instances.


Ubuntu has created their own page regarding this issue and they have issued fixes for the NTP package. Ordinary apt-get update and apt-get upgrade commands should update your packages to the latest versions that contain fixes for this particular issue. We recommend that everyone makes sure their system is regularly updated to ensure these security fixes arrive on your systems as well.



Minor security vulnerabilities revealed by an audit of OpenVPN, an open source security software providing a safer and more secure internet to millions worldwide, have been fixed. The Open Source Technology Improvement Fund, known as OSTIF, provided funding for the comprehensive security audit. OpenVPN 2.4.0 was audited for security vulnerabilities independently by QuarksLab and Cryptography Engineering between December 2016 and April 2017. The primary findings were two remote denial-of-service vulnerabilities. The issues discovered were minor in terms of security.


The denial of service vulnerabilities found have been fixed in OpenVPN 2.4.2 and 2.3.15 released on May 11, 2017. Likewise OpenVPN Access Server, the commercial version, has also been updated to fix those of the vulnerabilities that were found to be present in the OpenVPN Access Server code as well. OpenVPN Access Server version 2.1.6 and above address the issues found completely.



Google security researcher Tavis Ormandy recently found a bug in the Cloudflare service. You can read more about this on a recent blogpost by Cloudflare. The and website both sit behind Cloudflare, a popular content distribution network, for enhanced speed and security. After carefully reviewing the data we feel confident that information was not compromised on our web properties, since the features that are claimed to have been affected were not currently or previously enabled for either of our websites.


That aside and in case we missed something, it is always a good idea to change passwords when something like this occurs and it is never a bad practice to change passwords on a recurring basis. In other words, we recommend you change your passwords as a precaution. We do not store any Credit Card information or sensitive user information on either of our web properties, so even if there was in fact a leak, all they would get are passwords.

There were many other websites that you probably visit that sit behind Cloudflare, so we encourage you to please take a look at this list to see if there was a chance any other sites you have accounts on were possibly compromised. If so we advise you replace your passwords there as well just to be safe.



On April 7th of 2014 we were informed of the vulnerability dubbed Heartbleed (CVE-2014-0160), within one of the Internet's most significant security libraries (OpenSSL). A great number of services across the internet that use this library, including OpenVPN Access Server, may have been affected by this issue. Since learning of this issue, we have taken immediate necessary steps to ensure the security of OpenVPN and the OpenVPN Access Server product. Within 24 hours we have therefore released patches for specific versions of the Access Server that are affected, and we have released Access Server 2.0.6 with the fix for this issue already incorporated. If you are using an older version that contains the affected OpenSSL library you are advised to update immediately.

The affected versions of Access Server that contain the vulnerable OpenSSL library and are vulnerable to Heartbleed are:

  • OpenVPN Access Server 1.8.4 and 1.8.5
  • OpenVPN Access Server 2.0.0 / 2.0.1 / 2.0.2 / 2.0.3 / 2.0.4 and 2.0.5

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 on the client side is negligible. 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 which prevents this exploit from being successful. 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 did not take chances and have released a fix in OpenVPN Access Server 2.0.7 and newer versions, which incorporate updated clients as well. So update your clients as well.


If you have a version other than the aforementioned versions, you are not vulnerable to the Heartbleed vulnerability, but of course we always recommend to keep your system up-to-date. If you are running one of the mentioned versions, we recommend that you upgrade to the latest version available from our website immediately. Please be sure to note that you do need a valid (and not expired) license key in order to upgrade your OpenVPN Access Server maintain a licensed state of your server.

The OpenVPN Connect Client for Windows and macOS should also be updated, and you can do so by updating your OpenVPN Access Server first, and then downloading a new and updated copy of the OpenVPN Connect Client from your updated Access Server.

Note that mobile clients like on iPad, iPhone and Android devices, are not affected as they use PolarSSL instead, so no action needs to be taken there.



The OpenVPN Desktop Client is not receiving maintenance anymore, and has been deprecated for a while. All OpenVPN Access Server customers still using the OpenVPN Desktop Client for Windows should upgrade immediately to the OpenVPN Connect Client that comes bundled with our latest OpenVPN Access Server product. The OpenVPN Desktop Client is obsolete and is no longer maintained or available for download. This client contains a CSRF (Cross Site Request Forgery) vulnerability that can allow remote code execution by a malicious web site, as Stefan Viehböck, SEC Consult, has discovered. The OpenVPN Desktop Client also contains an older version of OpenSSL that has not received recent OpenSSL security updates. This advisory only applies to the OpenVPN Desktop Client app for Windows, and does not affect OpenVPN Connect Client, Private Tunnel, or OpenVPN open source builds for Windows.


We still see some users with this program actively in use. We strongly advise these users to switch to the newer client program titled OpenVPN Connect Client or an up-to-date OpenVPN open source alternative. We advise that you always try to use the latest version of the server and client software where possible.