OpenSSL fixes high severity security hole that could allow traffic to be decrypted

The OpenSSL project has pushed out version 1.0.2f of its open-source software widely used to encrypt many of the internet’s communications, after a high severity bug was found in OpenSSL’s code.

Many people are oblivious that OpenSSL is protecting their communications through encryption – perhaps because usually the only visual clue is the little green padlock you might spy in your browser’s URL bar when visiting a website using HTTPS.

But the truth is that many apps are using the OpenSSL code library to communicate securely via the internet.

So, when a security advisory was posted yesterday on the OpenSSL website it was worth sitting up and paying attention.

Here is the main meat of the security alert, focusing on the vulnerability (known as CVE-2016-0701) that is getting the most attention:

DH small subgroups (CVE-2016-0701)

Severity: High

Historically OpenSSL usually only ever generated DH parameters based on “safe” primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be “safe”. Where an application is using DH configured with parameters based on primes that are not “safe” then an attacker could use this fact to find a peer’s private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server’s private DH exponent if it’s reusing the private DH exponent or it’s using a static DH ciphersuite.

OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk.

So, the good news is that it appears that even if a popular application does use a vulnerable version of OpenSSL, it hopefully isn’t at risk from this particular vulnerability.

In other words, this flaw in OpenSSL is nothing like as serious as the notorious Heartbleed vulnerability made public in April 2014.

All the same, it makes sense for developers to rebuild their apps with the new, patched version of OpenSSL going forward.

Antonio Sanso was the researcher who discovered the security hole in OpenSSL, which saw the code reuse prime numbers in the Diffie-Hellman protocol, opening opportunities for attackers to decrypt supposedly securely encrypted communications.

For the technically minded, Sanso has written up a detailed analysis of the flaw.

What’s most impressive is the rapid turnaround by the OpenSSL security team, who were informed of the flaw on January 12, and had managed to confirm Sanso’s findings within a day, and publish a fix by the end of the month.

For more guidance and further reading, check out the advisory from OpenSSL.