This article examines the relationship between OpenVPN and OpenSSL, why the former depends on the latter, and why it's important to remain cognizant of software version numbers when one program is a critical dependency of another. Some of the same investigative techniques demonstrated here are also found in a related article - False Version Reporting in Ubuntu 16.04 - which explores a broader problem of incorrect program version reporting in Ubuntu, using OpenSSL to illustrate methods of identifying complex dependencies that may self-report erroneous version information to the operating system, and investigative procedures that can be used to discover its real version ID.
OpenVPN is an open source Virtual Private Network (VPN) software solution that rivals similar commercially available products. It allows the use of PKI (Public Key Infrastructure) and SSL/TLS certificates to establish secure connections between almost any networking device and a remote VPN server. OpenVPN relies on OpenSSL to manage much of its SSL and TLS cryptographic needs.
OpenSSL is an open-source, full-featured toolkit that provides support for Transport Layer Security (TLS) and Secure Socket Layer (SSL) cryptographic protocols. It is a cornerstone of many well-known staples of Linux, including OpenVPN. Originally released in 1998, OpenSSL is available for most Unix-like operating systems (e.g. Linux, Mac, and BSD) and Microsoft Windows.
For OpenVPN installation instructions on Ubuntu platforms, see 5 Ways to Install OpenVPN in Ubuntu.
OpenSSL's Influence Over OpenVPN
OpenVPN relies upon cryptographic libraries supplied by OpenSSL and mbedTLS. OpenVPN's dependency on them limits its range of possible cryptographic options to whatever protocols they provide. Practically speaking, OpenVPN is designed around OpenSSL 's crypto libraries exclusively, with mbedTLS (formerly PolarSSL) treated as the bastard step-child (i.e. an afterthought).
Pros and Cons of Code Dependencies
As the old saying goes, there's no sense in reinventing the wheel; unless, of course you're building a better wheel. In other words, if someone else has already written code for a particular function you need, it's better to borrow that code instead of spending time re-creating it.
Indeed, collaboration is a powerful tool, and a common tenet of software development. Typically referred to as "including" (importing) others' code when writing software, you may liken it to a form of recycling. Code sharing allows others to take advantage of the original author's work and relieves the borrower from the responsibility of maintaining a larger code base. It makes programs shorter and easier to write, and easier to reverse engineer and troubleshoot. In many cases the borrower is not an expert in the same functional area. Code sharing allows each contributor of a project to focus on their strengths and expertise.
Naturally, there is no reward without risk. A notable downside to code dependencies is the borrower has no direct control over the features (and bug fixes) of the dependency. The original program becomes partially (and in some cases wholly) dependent on the borrowed code. When one portion or the other undergoes change, something important may break. Particularly when it comes to security, it's generally a good idea to strive towards using the latest version of a program that is a dependency. This is especially true of interactive networking applications, such as client/server pairs (e.g. like VPN software). OpenVPN's relationship with OpenSSL is a good example of this phenomenon. Any change to the latter may significantly affect the former.
Reconciling Version and Feature Compatibility
OpenVPN depends on OpenSSL for many of its most important functions, relying on it for cryptographic functions. OpenVPN won't work at all without a cryptography library. As of this writing, OpenVPN only supports two (2) cryptographic libraries: OpenSSL and mbedTLS (formerly named PolarSSL). OpenSSL is the default, and is installed automatically during OpenVPN installation. OpenVPN's versioning is straightforward and consistent. You can read about it in another related article, OpenVPN Version List and Changelogs.
OpenVPN's tight dependency means it must remain cognizant of OpenSSL's capabilities by version. For example, when OpenSSL released version 1.1.0, support for SSLv2 connections was removed, requiring the use of SSLv3 only. If you upgraded to OpenSSL 1.1.0 on a client-side application, and subsequently attempted to access a server still using SSLv2, suddenly your access was broken. Is this a bad thing? That depends on your perspective. What is most important is OpenVPN needs to accomodate such scenarios. Although it cannot control OpenSSL's development, OpenVPN can control the narrative of its interaction with OpenSSL and adapt based on features that are present or not. However, since that's based on what it knows of OpenSSL version capabilities, what would happen if the installed version of OpenSSL were not reported correctly to OpenVPN? Think that doesn't happen? Think again. That is exactly the problem addressed in the related articles, False Version Reporting in Ubuntu 16.04 and Clear as Mud: OpenSSL and Ubuntu's Versioning System.
Making Sense of OpenSSL Versions
OpenSSL's versioning system is confusing. There are currently three (3) active branches of OpenSSL. Why are there multiple branches? OpenSSL has undergone major code changes from time to time. In order to avoid breaking existing software, these major releases are forks; independent code branches released at different times.
Just like Ubuntu, OpenSSL maintains a distinction between performance releases that are short-term in nature and so-called long-term release versions, which provide greater levels of stability and compatibility for integration in other software. All releases are supported for a limited period of time, but as the term implies, long-term releases are supported for a longer period of time (typically 3-5 years). In this context, "supported" means actively maintained by developers from the standpoint of security updates.
Regardless of which branch (version) you use, all of them are valid. Newer major versions have more features than older versions, but they are all maintained at the same level (as much as possible) from a security standpoint until reaching end-of-life. At that point they are still available, but may expose the user to lower levels of security.
Deciphering OpenSSL Version Numbers
OpenSSL's versioning nomenclature is confusing. It's not linear. There appear to be multiple "good" versions, and sometimes what seem like they would be older versions (based on their version number) are in fact newer. How do you know which version to use? Why are there multiple acceptable versions available? What are their differences?
In late November 2018, OpenSSL adopted a new naming format; ostensibly to reduce confusion. The new format is:
major version.minor version.patch
Or put another way, M.m.p where:
- M = Major version (integer)
- m = Minor version (integer)
- p = Patch (letter)
Here is a table showing which major branches of OpenSSL are currently receiving active support (security updates).
| OpenSSL Actively Supported Version Matrix | ||||||
|---|---|---|---|---|---|---|
| Major Version | Release Date | Status | End of Support | Minor Version | Release Date | LTS1 |
| 1.1.1 | 09.10.2018 | Active | 09.11.2023 | 1.1.1d | 09.10.2019 | Yes |
| 1.1.0 | 08.25.2016 | Deprecated | 09.11.2019 | 1.1.0l | 09.10.2019 | No |
| 1.0.2 | 01.22.2015 | Active | 12.31.2019 | 1.0.2t | 09.10.2019 | Yes |
| 1.0.1 | 03.14.2012 | Deprecated | 12.31.2016 | 1.0.1u | 09.22.2016 | No |
| 1.0.0 | 03.29.2010 | Deprecated | 12.31.2015 | 1.0.0t | 12.03.2015 | No |
As of this writing, if you're using one of those version numbers (currently 1.0.2t, 1.1.0l, or 1.1.1d) you're fine in terms of security and OpenSSL being up-to-date. However, that could change at any time. Versions 1.1.1 (1.1.1d), 1.1.0 (1.1.0l), and 1.0.2 (1.0.2t) were updated just a few weeks prior to this article being written. OpenSSL has historically been updated infrequently. Therefore, it is reasonable to presume these versions will continue to be "current" per se for some time.
While the 1.0.2 and 1.1.0 branches are (1.1.0) or soon will be (1.0.2) deprecated, they will continue to be at the same level of functionality and security integrity as the 1.1.1 branch until such time as another update is released for the 1.0.2 or 1.1.1 branches. After the 1.0.2 support window expires on 12/31/2019, watch for new 1.1.1 patches. Once that happens, if you're not already using 1.1.1, you will be placing yourself at risk. Needless to say, from a security standpoint the safe bet is: upgrade to the 1.1.1d branch now if you're not using it already. Makes sense, right? Maybe. Let me tell you why you might not want to.
Upgrade Now, or Later?
IT Security folks don't like to hear this, but I'll argue there can be good reasons not to upgrade OpenSSL immediately. Sometimes, the "best" course of action isn't actually the best when all potential repercussions are evaluated. I blame OpenSSL's confusing and inconsistent versioning for this fact. With three (3) legitimate branches or "forks" of OpenSSL maintained simultaneously for some time, they are obviously not the same. Those differences could be enough - in some cases - to cause switching versions to break functionality in other programs that depend upon OpenSSL.
Why would I even mention the possibility of limping along with deprecated or soon-to-be-deprecated software? I'm a realist. OpenSSL is not a standalone application. If you can't afford to possibly break another program that depends on OpenSSL, it may be worth waiting a little longer until 1.1.1 is your only option. On the other hand, not upgrading to the current branch obviously creates its own set of risks. You will have to weigh the potential risks of your own situation. Just remember, sooner or later you will have to move to the 1.1.1 branch if you're not already using it.
The proverbial silver lining is (while not especially helpful in the short term), OpenSSL appears to be gravitating toward a single stream consolidation (1.1.1). That hasn't been the norm in nearly 10 years (there have been multiple production forks since early 2010), and I for one am eagerly looking forward to the possibility of returning to a single-stream model. Either way, I expect technical hiccups in various applications that depend on OpenSSL as the older 1.0.2 and 1.1.0 branches are allowed to expire.
There's no guarantee of a smooth transition.
| OpenSSL & Data Transport Security | ||||||
|---|---|---|---|---|---|---|
| OpenSSL Version | SSL v2 | SSL v3 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
| 1.1.1 | No | Yes | Yes | Yes | Yes | Yes |
| 1.1.0 | No | Yes | Yes | Yes | Yes | No |
| 1.0.2g | No1 | Yes | Yes | Yes | Yes | No |
| 1.0.2 | Yes | Yes | Yes | Yes | Yes | No |
| 1.0.1 | Yes | Yes | Yes | Yes | Yes | No |
| 1.0.0 | Yes | Yes | Yes | Yes | No | No |
| <1.0.0 | Yes | Yes | Yes | No | No | No |
Does Version Really Matter?
Now that we've established which versions are currently maintained, how do you know which version you need? How do you know if the version you are using is outdated or serves your needs?
This chart shows which TLS and SSL versions are supported by which OpenSSL versions. OpenSSL versions are listed vertically on the left, from top to bottom in order of most recent to oldest.
As you can see, only OpenSSL 1.1.1 supports TLS 1.3. Therefore, if you want the best available encryption, you will need to upgrade to 1.1.1 if you're not using it already.
The next section will discuss this exact issue: how much security do you need?
Bringing It All Together: OpenVPN, OpenSSL, SSL/TLS
Making an educated choice of VPN software requires a rudimentary understanding of encryption protocols. VPN software and cryptographic libraries are not created equally. Even if a specific software - such as OpenVPN - seems a logical choice, it's prudent to gain a basic understanding of what to look for when it comes to protecting your identity and the contents of your data transmissions over the Internet. We are all accustomed to taking for granted that our data is sufficiently protected in transit and on remote servers where it is stored. Rarely, does the average person consciously question how the process works. This is likely fine for web surfing and casual Internet usage. But when it comes to VPNs connections, there is a wide variety of possibilities. VPNs are a corner of the Internet that remains much like the Wild West.
| SSL/TLS Status | |||
|---|---|---|---|
| Protocol | Status | Born | EOL1 |
| SSL v1 | No public release | -- | -- |
| SSL v2 | Deprecated | 1995 | 20112 |
| SSL v3 | Deprecated | 1996 | 20152 |
| TLS 1.0 | Near EOL | 1999 | 20203 |
| TLS 1.1 | Near EOL | 2006 | 20203 |
| TLS 1.2 | Active | 2008 | ---- |
| TLS 1.3 | Active | 2018 | ---- |
SSL and TLS
The chart to the right provides a bird's eye view of SSL and TLS standards.
SSL stands for Secure Socket Layer. It is a standard security technology for establishing an encrypted link between two devices operating in a client/server architecture model, such as a web browser and web server.
TLS stands for Transport Layer Security and is cryptographic protocol that encapsulates data transmissions from end to end in a secure "wrapper."
What is the difference between the two? They are both secure communications with two (2) primary functions:
- A secure "handshake" when a connection between two remote devices is established over an IP connection; and
- An encryption "wrapper" that encapsulates the actual content during transport.
Both are considered to be an "end-to-end" encryption or data protection solution. SSL was deprecated in June 2015 by IANA (see RFC 7568) and it was officially "turned off" on June 30, 2018 by most organizations. SSL is considered obsolete and should not be used. It is no longer effective for security and is considered insecure.
TLS 1.3 is the current standard for encrypted data transmissions, though TLS 1.2 is still widely used. For the moment, TLS 1.2 appears to be sufficient, but users should plan on transitioning to TLS 1.3 as soon as is practical.
We could easily get down in the weeds here, but suffice it to say any organization transmitting personal financial information was supposed to stop using SSL as of 30 June 2018. What happened? In late 2014/early 2015, security researchers realized the SSL architecture had too many security vulnerabilities for it to continue to be effective in preventing certain types of hacking attempts, and it needed to be phased out. TLS already existed and was known to be a stronger security protocol with similar capabilities, so the transition began.
Choosing an OpenVPN Version
After digesting the guidance above, you should be forming an idea of what to look for in terms of OpenVPN support.
As a general rule, you should install the latest version unless there is some reason why you can't use it, such as a compatibility issue (e.g. with OpenSSL). When your choices are wide open, install the version with the broadest range of support for encryption protocols. As of this writing that means installing OpenVPN 2.4.7 and OpenSSL 1.1.1d, which together will provide you with the ability to use TLS 1.3 and robust RSA ciphers such as AES 256/SHA 512.
Two charts below summarize the most recent branches of OpenVPN (2.4 and 2.3). Any branches below 2.3 should be avoided (even 2.3 is sketchy). Glancing over these charts, you will find references to common ciphers, highest supported TLS version, and the impact of OpenVPN/OpenSSL combinations relative to OpenVPN features. You'll also find a record of current CVE (Common Vulnerabilities and Exposures)4 security vulnerabilities reported against the corresponding OpenVPN version and OpenSSL version in each row. The latter gives you an idea of your security vulnerability profile should you choose to use the given combination of the two programs. As you can see in the chart, implementing older versions of OpenVPN and OpenSSL together yields the greatest risk to security vulnerabilities, and vice-versa.
A more comprehensive summary of OpenVPN versions is available in the related article, OpenVPN Version List and Changelogs.
How to Read the Charts Below
The left two (2) columns indicate a specific OpenVPN version and its release date. To their right, cross reference the TLS, available ciphers, and CVE vulnerabilities. Note the capabilities and risks of any particular OpenVPN version are directly correlated with the version of OpenSSL in use. The 4th column identifies the version of OpenSSL associated with the data in each row. Take into consideration the combination of OpenVPN and OpenSSL, their capabilities and limitations.
| OpenVPN 2.4 Branch (Current) | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OpenVPN Version | Release Date | Best TLS | OpenSSL | Ciphers4 | CVE Bugs5 | ||||||||
| HMAC | AES 256 |
SHA-3 | SHA-2 (512) |
SHA-2 (384) |
SHA-1 | CAM | SEED | OVPN | OSSL | ||||
| 2.4.7 | 02.18.2019 | TLS 1.3 | 1.1.1d | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 0 |
| TLS 1.3 | 1.1.1 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 8 | ||
| TLS 1.2 | 1.1.0 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 26 | ||
| TLS 1.2 | 1.0.2 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 65 | ||
| 2.4.6 | 04.19.2018 | TLS 1.2 | 1.1.1 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 8 |
| 2.4.5 | 02.28.2018 | TLS 1.2 | 1.1.0h | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 9 |
| TLS 1.2 | 1.1.0 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 26 | ||
| TLS 1.2 | 1.0.2g | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 32 | ||
| TLS 1.2 | 1.0.2 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 65 | ||
| TLS 1.2 | 1.0.1 | Yes | Yes | No | No | Yes | No | Yes | Yes | 0 | 64 | ||
| TLS 1.0 | 1.0.0 | Yes | No | No | No | No | Yes | Yes | Yes | 0 | 58 | ||
| 2.4.4 | 09.25.2017 | TLS 1.2 | 1.1.1 | Yes | No | No | No | Yes | No | Yes | Yes | 8 | 8 |
| 2.4.3 | 06.21.2017 | TLS 1.2 | 1.1.0h | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 9 |
| 2.4.2 | 05.11.2017 | TLS 1.2 | 1.1.0 | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 26 |
| 2.4.1 | 03.21.2017 | TLS 1.2 | 1.0.2g | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 32 |
| 2.4.0 | 12.26.2016 | TLS 1.2 | 1.0.2 | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 65 |
| TLS 1.2 | 1.0.1 | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 64 | ||
| TLS 1.0 | 1.0.0 | Yes | No | No | No | No | Yes | Yes | Yes | 8 | 58 | ||
The 2.3 branch table - seen below - differs slightly from the 2.4 branch due to differences in supported ciphers (the 2.3 branch's supported cipher set is older than the 2.4 branch). Notice the supported cryptographic standards are dependent on the version of OpenSSL installed.
| OpenVPN 2.3 Branch (Previous) | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| OpenVPN Version | Release Date | Best TLS/SSL | OpenSSL | Ciphers4 | CVE Bugs5 | ||||||
| HMAC | AES 256 | SHA-3 | SHA-2 | SHA-1 | OVPN | OSSL | |||||
| 2.3.4+ | Various | TLS 1.2 | 1.1.1 | Yes | Yes | No | Yes | -- | 1 | 8 | |
| 2.3.3 | 04.08.2014 | TLS 1.2 | 1.1.0h | Yes | Yes | No | Yes | -- | 1 | 9 | |
| TLS 1.2 | 1.1.0 | Yes | Yes | No | Yes | -- | 1 | 26 | |||
| TLS 1.2 | 1.0.2g | Yes | Yes | No | Yes | -- | 1 | 65 | |||
| TLS 1.2 | 1.0.2 | Yes | Yes | No | Yes | -- | 1 | 65 | |||
| TLS 1.2 | 1.0.1 | Yes | Yes | No | Yes | -- | 1 | 64 | |||
| TLS 1.0 | 1.0.0 | Yes | No | No | Yes | -- | 1 | 58 | |||
| < 2.3.3 | 05.31.2013 | TLS 1.0 | 1.1.0 | Yes | No | No | Yes | -- | 2 | 26 | |
More Information
Still seeking more info?
- How VPNs Work
- Why Do You Really Need (or Want) a VPN?
- Choosing the Right VPN Provider
- Who Watches the Watchers? Reviewing VPN Reviewers
- OpenVPN Version List and Changelogs
- 5 Ways to Install OpenVPN in Ubuntu
- False Version Reporting in Ubuntu 16.04
Footnotes
1 A Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol and software that enables remote access servers to communicate with a central server to authenticate dial-in users and authorize their access to the requested system or service. Note that "dial-in" is not literal. It refers to any attempt to initiate a connection that begins externally from the server and involves a connection attempt on the network port assigned to the RADIUS server.
2 IETF prohibits SSL v3. RFC 7568.
3 TLS 1.3 standard: See RFC 8446.
4 AES = Advanced Encryption Standard | SHA and SHA-1 are Secure Hash Algorithms | CAM = CAMELLIA | SEED
5 Common Vulnerabilities and Exposures, maintained by Mitre Corporation. A related resource is CVE Details, a very useful CVE search engine site. Note that in the tables, "OSSL" is an abbreviation for OpenSSL.
References
SHA-2 Overview [SHA-2]
SHA-3 Overview [SHA-3]
SHA-2 needs TLS 1.2+ [SHA-2 with TLS 1.2 or higher only]
OpenVPN deprecated SHA-1 Certificate Authorities in 2.4.5 [OVPN 2.4.5 deprecated SHA-1 CA's]
SHA-2 384 keysize fails <2.4.4 [SHA-2 384 key size fails on OVPN 2.4.3 and below]
SHA-3 support deemed not worthwhile for the time being [SHA-3 not supported by OVPN Servers (EasyRSA)]