You must have noticed the discovery of another serious vulnerability of the OpenSSL encryption library. It was repaired immediately and today’s article will inform you about the issue, tell you if this vulnerability concerns your server and if you need to correct it.
Vulnerabilities in OpenSSL Appear Regularly
The discovery of any OpenSSL encryption library vulnerability always gets a lot of reaction. Not positive reactions, though, because since the well known Heartbleed bug from last year, several vulnerabilities have been discovered. They complicate the work of administrators who have to keep repairing servers and keep up sufficient security; and they neither help create a good name for Open Source software nor encourage users’ trust in it.
The Principle of Vulnerability and its Results
The last discovered vulnerability, which means a security gap, was a so-called certificate forgery. The vulnerability enables attackers to bypass the verification of a certificate’s chain of confidence and enables man-in-the-middle attacks (eavesdropping on communication by a third party). Open SSL (since versions 1.0.1n and 1.0.2b) has been trying to find alternative ways to the root certificate during verification if the first attempt fails.
A mistake in implementation has allowed the attacker to bypass some untrustworthy certificate checks and consequently use their own certificate as a certification authority issuing fraudulent certificates. OpenSSL does not have a problem with these certificates’ trustworthiness. To be specific, it is an X.509 Basic Constraints cA check.
We need to stress that the mistake is by no means of Heartbleed proportions. With this vulnerability, the likelihood of practical misuse is a lot lower because OpenSSL libraries are not used by web browsers. Browsers are immune to the vulnerability and uncover a false certificate thanks to their verification mechanisms, which are independent of OpenSSL (Explorer, Firefox, Safari a Chrome). A false verification can happen during communication between two servers, when OpenSSL would be used to verify a certificate. However, this does not happen very often.
How to Verify Your Server’s Vulnerability
Fortunately, vulnerability does not concern all OpenSSL versions. The four OpenSSL versions affected are named below. You will find out which OpenSSL version is installed on your server by putting this command in the terminals
dpkg -s openssl | grep 'Version'
Four OpenSSL versions need to be patched; the vulnerability CVE-2015-1793 concerns only versions 1.0.2c, 1.0.2b, 1.0.1n, 1.0.1o.
OpenSSL versions 1.0.2b and 1.0.2c need to upgrade to version 1.0.2d; versions 1.0.1n and 1.0.1o should be upgraded to 1.0.1p.
If You Do Not Trust OpenSSL, Try its Alternatives
We wish the OpenSSL developers more luck when checking for mistakes in this package and fewer vulnerabilities for the future. If you have given up on OpenSSL, you could consider trying an alternative, such as LibreSSL (developed and used by OpenBSD) or BoringSSL. The authors of Boring SSL (an alternative by Google) were the ones to report the mistake to the OpenSSL fund on 24th June 2015.
- The OpenSSL “CVE-2015-1793” certificate verification bug – what you need to know
- OpenSSL Security Advisory [9 Jul 2015]
Bc. Jindřich Zechmeister
Specialist in security SSL certificates
Certified Symantec Sales Expert Plus