ubuntu – Server Still Vulnerable to Heartbleed After Updating OpenSSL

Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there.

Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012.

So, I'm going to go ahead and assert that openssl version -a is the proper, cross-distro way to display the full version of OpenSSL that's installed on the system. It seems to work for all the Linux distros I have access to, and is the method suggested in the help.ubuntu.com OpenSSL documentation, as well. Ubuntu LTS 12.04 shipped with vanilla OpenSSL v1.0.1, which is the version that looks like an abbreviated version, on account of not having a letter following it.

Having said that, it appears that there is a major bug in Ubuntu (or how they package OpenSSL), in that openssl version -a continues to return the original 1.0.1 version from March 14, 2012, regardless of whether or not OpenSSL has been upgraded to any of the newer versions. And, as with most things when it rains, it pours.

Ubuntu is not the only major distro in the habit of backporting updates into OpenSSL (or other packages), rater than relying on the upstream updates and version numbering that everyone recognizes. In the case of OpenSSL, where the letter version numbers represent only bug fix and security updates, this seems nearly incomprehensible, but I have been informed that this may be because of the FIPS-validated plugin major Linux distros ship packaged with OpenSSL. Because of requirements around revalidation that trigger due to any change, even changes that plug security holes, it is version-locked.

For example, on Debian, the fixed version displays a version number of 1.0.1e-2+deb7u5 instead of the upstream version of 1.0.1g.

As a result, at this time, there is no reliable, portable way to check SSL versions across Linux distributions, because they all use their own backported patches and updates with different version numbering schemes. You will have to look up the fixed version number for each different distribution of Linux you run, and check the installed OpenSSL version against that distribution's specific version numbering to determine if your servers are running a vulnerable version or not.

A certificate isn't vulnerable, or otherwise, to heartbleed. A certificate is just a certificate. There have been crypto issues in the past, particularly with respect to the RNG of choice, that caused weak keys (and thus vulnerable certificates) to be created, but heartbleed isn't a vulnerability of that type.

A key/certificate pair can have been compromised by heartbleed, irrespective of the version of OpenSSL with which it was created or even if it was created by a completely different SSL implementation, if it was used on a server that offered TLS services to the public using a vulnerable version of OpenSSL.

If it was not so used, it cannot have been compromised by heartbleed, even if it was created on a server that at that time was running a vulnerable version of OpenSSL.

(Now for the life's-more-complicated-than-you-would-like bit: if you created the key/certificate pair (or key/CSR pair) on a server and that server was at that time running a vulnerable version of OpenSSL and you were connected to that server by a method vulnerable to exploit (eg OpenVPN, but not OpenSSH) and you exposed the contents of the created keyfile to the connection stream, eg by cat'ing the file or by copying it over the connection, then it is possible that the certificate could have been compromised. But that's still not a vulnerability in the certificate as such, and it's not detectable by examination of the certificate (or any other way, as far as I am aware).