Yesterday the OpenSSL project made available updates for version 1.0.2c and 1.0.1o of its OpenSSL cryptographic library. The updates bring the version numbers up to 1.0.2d and 1.0.1p respectively. These updates resolve a critical issue that was introduced inadvertently in the June 2015 security updates for the above mentioned OpenSSL branches.
The security issue CVE-2015-1793 (definition of the term CVE) involves a check by the OpenSSL library to verify the authenticity of TLS certificates. If the first attempt to locate a certificate validation chain is not successful the code will look elsewhere to verify authenticity and it is a bug in how this alternative certificate validation chain is verified where this security issue could occur.
If an attacker could convince you to visit a malicious website, this website could be signed using a fake certificate but due to this bug in OpenSSL this fake certificate would appear to be legitimate and thus would not cause any suspicion (namely that the green padlock icon would still appear in your web browser). This malicious website could be used in a phishing attack to make a fake site appear like the real site it’s impersonating and thus you may be inclined to enter your login credentials for the legitimate site but actually be providing these details to a person with malicious intent. For this attack to occur, the attacker must already be on the network path between the client and the server i.e. a man in the middle attack (MITM, MITM defined) thus reducing this attacks feasibility.
How can I protect myself from this issue?
If you don’t manage a web server/website that uses the OpenSSL library you are not affected by this issue. Web browsers such as Mozilla Firefox, Google Chrome, Apple Safari and Internet Explorer are not affected by this issue since they don’t use OpenSSL. In addition, where 2 servers running OpenSSL communicate with each other they are not affected by this issue (this issue occurs only in a client and server interaction and not server to server).
Google Chrome since version 38 actually uses a custom code fork of OpenSSL known as BoringSSL. The OpenSSL project attributed the discovery of the security updates being discussed in this post to the BoringSSL team. Further information on BoringSSL is available in this blog post.
For any server that you manage that uses OpenSSL, please update your OpenSSL installations to 1.0.1p or 1.0.2d (as appropriate). FTP mirrors to obtain the necessary downloads are available from here. Downloadable Tarballs (compressed/packaged code made for distribution) are available from here. It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation.
OpenSSL also took the opportunity to re-iterate that versions 1.0.0 and 0.9.8 will cease to receive security updates from the 31st of December 2015. Users of these versions should upgrade before this deadline.
We can expect many more of these updates from OpenSSL as the year progresses. This is good news since everyone that uses OpenSSL (either on their web server or within their software) benefits from the fixes that are released. The frequency of updates has increased since the OpenSSL project received funding last year from the Core Infrastructure Initiative which supports critical open source projects upon which the internet and the global information infrastructure relies on. In addition, an audit and code clean up of the OpenSSL project is taking place which should also improve the projects security and long term stability/maintainability.