Clear as Mud: OpenSSL and Ubuntu's Versioning System

I wrote a separate article on versioning errors in Ubuntu (False Version Reporting in Ubuntu 16.04) and used OpenSSL as an example to illustrate the confusion false versioning creates, particularly when the program in question is a critical dependency of something important, such as networking and cryptography. OpenSSL is challenging to follow from a versioning and feature perspective. When your operating system gives you false version information on it, that simply adds insult to injury. So, in this article I'll demonstrate how to identify the version of OpenSSL you really have, and the differences between major forks of OpenSSL.

Clarification on why I wrote this article

This article is one of several that seeks to bring awareness to what I perceive as inconsistent behavior in Ubuntu.

There is some controversy with regards to how Ubuntu backports bug fixes. Yes, it's quite common for open source platforms to update a program and fix bugs without upgrading to a new release. Some folks argue that Ubuntu (ostensibly) backports bugfixes, including security fixes; that by design Ubuntu does not upgrade packages within a release. I disagree. There are examples where the opposite is true. Is this semantics, or is the process broken?

To wit: 1) Many updates to OpenSSL ARE simply bug fixes; and 2) "upgrading" a version of OpenSSL installed via Ubuntu's packaging system - most of the time - does not actually upgrade. It updates. OpenSSL isn't the only package that exhibits this inconsistent behavior, but IMHO it is one of the best examples exemplifying the confusion caused by this inconsistent behavior of the update/upgrade process in Ubuntu.

Verifying Ubuntu's Version of OpenSSL

OpenSSL may be updated manually via packages, during the installation of progams that rely on it (such as OpenVPN), or manually by building from source code. The latter is great when you know what you're doing and have the desire to do so, but most people install OpenSSL via packages or when it's triggered by another installer. Unfortunately, if those installers perceive incorrect information regarding the existing version of OpenSSL, they may run the wrong update or fail to update it at all. And if you're updating it manually, you'll want to know what your starting point is. For these reasons, it's good to know how to check the current version (if it's installed at all).

To check your current OpenSSL version in Ubuntu and most other Linux distributions, the command is:

openssl version

Ubuntu will report different version numbers for OpenSSL, depending on which version and sub-version of Ubuntu you are using. The following is a general guide. Your experience may differ slightly, especially if you are using a build of Ubuntu which is not the original (e.g. 20.04 first release) or most recent/final release of a given Ubuntu version (e.g. 18.04.6):

  • Ubuntu 22.10 (pending): Version 3.0.5-2 *unstable*
  • Ubuntu 22.04 (first release): Version 3.0.2 released 15 Mar 2022
  • Ubuntu 21.10 (final release): Version 1.1.1l released 24 Aug 2021
  • Ubuntu 20.04 (final release): Version 1.1.1g released 21 Apr 2020
  • Ubuntu 20.04 (first release): Version 1.1.1c released 28 May 2019
  • Ubuntu 18.04 (final release): Version 1.1.1c released 28 May 2019
  • Ubuntu 18.04 (first release): Version 1.1.0g released 2 Nov 2017
  • Ubuntu 16.04: Version 1.0.2g released 1 March 2016

Outdated OpenSSL versions is one of the primary reasons why it's wise to either keep your server versions of Ubuntu relatively updated, or learn how to and implement a plan for updating your security packages periodically on older versions of Ubuntu. Even with automatic updating and security updates enabled, Ubuntu will not always update important packages such as OpenSSL. In fact, OpenSSL integration with Ubuntu requires a huge amount of extensive testing, which is why non-current versions of Ubuntu have it updated so rarely (if at all).

To illustrate this point, glancing at the information above, it appears as if Ubuntu 16.04's OpenSSL was hardly ever updated. Let's cross reference that with a table of OpenSSL versions. As you can see, the final version of OpenSSL in Ubuntu 16.04 did not enjoy long-term support from the OpenSSL side of the equation. From this information, we can deduce two noteworthy pieces of information: 1) The last version of OpenSSL supported by Ubuntu's core development team for Ubuntu 16.04 did not enjoy long-term security support from the OpenSSL side of the equation; and 2) This means Ubuntu 16.04's OpenSSL security became obsolete pretty quickly, and ideally users should have been compelled to quickly adopt Ubuntu 18.04 soon after it was released, for this reason. Unfortunately, many users could have stuck with Ubuntu 16.04 for quite some time due to familiarity and the fact Ubuntu supported it long-term. However, just because Ubuntu supported it for a long time does not mean its level of security (from an OpenSSL perspective) was maintained at a high level. As just explained and proven, this was in fact not the case. Unfortunately, it's likely that most Ubuntu 16.04 users at that time didn't have any idea this was the case.

OpenSSL Versions (TLS/SSL Support)

1 Long Term Support version

2 Common Vulnerabilities and Exposures

3 Disabled by default; can be force-enabled if compiled from source code

OpenSSL Version Support Matrix
Minor Ver Release Date Major Ver Release Date Status End of Support LTS1 CVE Vuln2 TLS 1.3 TLS 1.2 TLS 1.1 TLS 1.0 SSL v3 SSL v2
1.1.1d 09.10.2019 1.1.1 09.10.2018 Active 09.11.2023 Yes 1 Yes Yes Yes Yes No3 No3
1.1.0l 09.10.2019 1.1.0 08.25.2016 Deprecated 09.11.2019 No 0 No Yes Yes Yes No3 No3
1.0.2t 09.10.2019 1.0.2 01.22.2015 Deprecated 12.31.2019 Yes 0 No Yes Yes Yes No3 No3
1.0.1u 09.22.2016 1.0.1 03.14.2012 Deprecated 12.31.2016 No 1 No Yes Yes Yes Yes No3
1.0.0h 03.12.2012 1.0.0 03.29.2010 Deprecated 12.31.2015 No 0 No Yes Yes Yes Yes No3
0.9.8n 03.24.2010 0.9.8 07.05.2005 Deprecated 12.31.2015 Yes 33 No No No No Yes Yes
0.9.7m 02.23.2007 0.9.7 12.23.2002 Deprecated 12.31.2015 Yes 23 No No No No Yes Yes
0.9.6m 03.17.2004 0.9.6 09.24.2000 Deprecated 12.31.2015 Yes 29 No No No No Yes Yes

The chart above shows the major and most recent minor releases over the last 22 years or so. You obviously don't want to use those old versions, but I decided to print them here as reference points. If you install OpenVPN in Windows, depending on the version, you might actually end up with an OpenSSL 0.9.8 branch. Shocking, but true! And believe it or not, this is not a comprehensive list, but it does provide perspective on how recent or old each version is going back quite far.

The "Major Ver[sion]" is very important. This column represents the nomeclature of OpenSSL major code branches. As you can see, the "active" branches are not linear. Notice the 1.0.2 branch is still valid, but the current patch version is letter t. It's also much more recent than the 1.0.2.g version reported by Ubuntu 16.04 from the version check noted above (March 2016). So, the version reported by Ubuntu does indeed appear to be quite outdated. That certainly seems like a big disparity, and quite frankly I'm surprised the developers at Canonical (the publisher of the Ubuntu operating system) would allow that oversight to go unnoticed for such an important function as a crypotgraphic library. In fact, that thought right there ought to raise a red flag in your mind. Is that reported version correct? Maybe. Maybe not. It is certainly suspicious.

Getting back to your Ubuntu device and verifying your OpenSSL version, it certainly looks like the current version is quite old. Since we are talking about an important security process here, it's likely not a good idea to be using outdated software (at least not THAT outdated). You could just stop here, update OpenSSL via the official repository package installer, and go on about your day. However, the next time you checked your version, you would find it has the exact same version as before. It's as if you can't update it. In fact, on that machine I tried exactly those steps, and sure enough... that is what happened: no change. What gives? To get to the bottom of this, one has to perform some investigative work. We have, unfortunately, uncovered one of the weaknesses of Ubuntu's software packaging system, which is that a program can be updated without registering a version change, and the average end user will be none the wiser. Running the same version check afterwards, it appears as if there have never been any updates.

Time for some detective work to figure out what the heck is going on.

Ubuntu's Quirky Package System

It's not uncommon for Ubuntu users to discover a program's version information and conclude they are running a terribly outdated version. It's particularly vexxing when pertaining to network security or data security. The vast majority of the time, the software on your system is actually up-to-date or very close to it (of course there is going to be some lag time). The issue is Ubuntu's confusing package versioning nomenclature.

Ubuntu has two layers of program versioning.

Package Versions

This is the versioning system for pre-built packages acquired and installed via Aptitude (apt). They have names like this:

Package: openssl (1.0.2g-1ubuntu4.15 and others) [security]

Program Versions

Meanwhile, if you checked the version number of your currently installed OpenSSL program, Ubuntu would return something like this (from Ubuntu 16.04.5):

OpenSSL 1.0.2g 1 Mar 2016

Notice they both indicate OpenSSL version 1.0.2g. The version number OpenSSL reports is over 3-1/2 years old! Alarming, to say the least since we are talking about networking security here! However, that's not the whole story. Is your shock and sense of alarm warranted? Let's find out. While this information is useful, when you have a program such as OpenSSL that is widely engrained into many applications, version numbers can become clear as mud. If you have concerns; if you don't trust the Ubuntu gurus at Canonical 100%, you need to dig deeper. Review the change log for the OpenSSL package and there you can find out what the heck is going on.

BTW, you may alternatively use apt-get changelog openssl to view version changes via the command terminal.

Point a web browser to the Ubuntu Packages Search website.

Perform a search for OpenSSL.

  • Find the "Search" section
  • Type "openssl" in the Keyword search field
  • Select the appropriate distribution name under the "Distribution" dropdown (your Ubuntu distribution name)
  • Make sure the "Search on" radio button has "Package names only" selected
  • Click the Search button
  • Find the OpenSSL package information and click it

You will see something like this:

Locate the link "Ubuntu Changelog" and click it.

This takes you to the Change Log for the current package. Here you can see all the updates to this package, with the most recent changes at the top of the screen.

In this case, we can see the latest change was published on 26 February 2019 and contained a security update. Scrolling all the way to the bottom, we can see the very first release is from 22 November 1996, and it's not even OpenSSL. Poking around some more, we find the initial release of the OpenSSL code is from 31 March 1999. So, here we have the entire history of this package, and as you can see it's very lengthy. Also note the current package version is an amalgamation of decades of related code versions. This is a history of everything that's happened with this package.

These Version Numbers Don't Make Sense

At this point you ought to be thinking to yourself this seems rather odd. The OpenSSL build in Ubuntu 16.04 appears to be labeled as version 1.0.2g. Meanwhile, if you review the OpenSSL version chart again, you'll note major version 1.0.2 is still supported ("Older version, still supported"), but the latest version is indicated as 1.0.2t with a date of 10 September 2019. Well, if we were using a version even close to 1.0.2t, it would be a heckuva lot more recent than 1.0.2g, which is what is reported by querying OpenSSL's version via the command line in terminal. And OpenSSL also reports its build date is from March 2016. Yet on the other hand, we just checked the change log for the Ubuntu package for OpenSSL and it was updated in February 2019. What gives? This data is all over the place. How do we know which version is truly installed right now, and which data source to believe?

Next, if you wish you may correlate this information with the official OpenSSL builds.

What To Do: Ubuntu 16.04.x or 18.04.x

TLDR; Nothing.

Afraid your OpenSSL in Ubuntu 16.04 is horribly outdated? It's not.
What you are experiencing is a common quirk of Ubuntu due to how it reports application package versioning.

If you're running an Ubuntu 16.04 platform, you're likely using the old OpenSSL 1.0.2g. The good news for you is that OpenSSL branch (1.0.2) is a Long Term Support version of OpenSSL that is still supported (until 31 December 2019). It also means sooner or later, someone is going to release an updated repository with an updated version of OpenSSL for Ubuntu 16.04. After the end of 2019 though, you'll be out-of-luck. While that is unlikely to be a problem for awhile (OpenSSL is updated very infrequently), it will eventually become a sore point. I suspect by that time you will have (or should have) upgraded to Ubuntu 18.04 anyway. It's likely to be a non-issue regardless.

But, that version of OpenSSL on my Ubuntu 16.04 server is over 3-1/2 years old! What the heck?! Why should I believe you when you're telling me not to worry about it? Well, now we get into the screwball versioning of Ubuntu, so I can explain how the combination of two (2) screwball versioning systems confuses the heck out of almost every Ubuntu user.

Bottom Line: The official Ubuntu package installers for OpenSSL ARE maintained.

You can almost ignore the date when you run the version command to check which version of OpenSSL you're running. I say "almost" because it is good to know which base version you are using (1.0.2g in this case). What's happening here is a disconnect between the Ubuntu version numbering of its OpenSSL program and the version number of the official OpenSSL release. This causes some people to (incorrectly) conclude their OpenSSL version is outdated, when it is not exactly, but may be partially.

First, there is no way to know from viewing the changelogs whether the underlying code of the program has been updated in a manner that would make it consistent with a more recent release, if it had been built from source code. Second, what one can ascertain is that any described bug fixes have been implemented within Ubuntu. The problem - as I've been endeavouring to point out in this article - is in the case of programs (such as OpenSSL) that are critical dependencies of other programs - this issue takes on much more significance than updating a "normal" or common program that is likely to stand on its own. OTOH, there are very likely pre-existing hooks used by other programs that depend on OpenSSL, which could be broken if it were truly upgraded. Then again, if one adopts that conservative point-of-view, how can you ever update any program? We can get into circular pretzel logic discussions here pretty easily.

Manual updates to OpenSSL risk breaking other programs, but that is not the problem of Ubuntu's packaging system. Broken packages as a result of an infrastructure update are indicative of an entirely different issue: poor programming practices.

Even if that doesn't happen (broken packages), the end result is - from a practical perspective - in this case the user doesn't truly know which version of OpenSSL they have. What Ubuntu reports after a package update is inaccurate any way you look at it. At the very least, the information is misleading. If the version number notation is the same, but the underlying code has changed, how is that still the same version? The philosophy behind this technique and version reporting needs to change. It should be transparent, not clear as mud (as it is now).