OpenSSL provides open source implementations of the Secure Sockets Layer and Transport Layer Security protocols that enable communications between Web browsers and servers to be encrypted, via what's known as HTTPS.

But a newly disclosed critical security flaw centers on how OpenSSL uses the Diffie-Hellman algorithm for TLS connections. In some cases, the numbers generated by the algorithm - designed to secure communications between two systems - may be "non-safe primes," leaving them susceptible to an attacker potentially identifying them and then decrypting related communications, the OpenSSL project warns in a Jan. 28 security advisory.

The U.S. Computer Emergency Response Team recommends all OpenSSL version 1.0.2 users upgrade immediately to get a related fix. "OpenSSL prior to 1.0.2f will by default reuse this [private] number for the life of the process," US-CERT vulnerability analyst Garret Wassermann says in a related security alert. "Such a number, particularly if reused, severely weakens applications of the Diffie-Hellman protocol such as TLS, allowing an attacker in some scenarios to possibly determine the Diffie-Hellman private exponent and decrypt the underlying traffic."

The fix arrived just two weeks after the flaw was first reported to OpenSSL - on Jan. 12 - by Adobe software engineer Antonio Sanso, who's also vice president of the Apache Software Foundation. He says in a blog post that he built a proof-of-concept "simple" attack using "a verbatim application of a classical paper" published in 1997, and that unlike some recent crypto attacks that forced a cipher suite to downgrade to a weak key that could be cracked, this attack dispenses with the downgrade and simply compromises the private key.

OpenSSL says it doesn't believe the flaw is widespread, owing to many users employing an OpenSSL option - "SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS" - that prohibits a server from reusing a Diffie-Hellman exponent for the life of a server process. "It is believed that many popular applications do [use] this option and would therefore not be at risk," the OpenSSL project says.

Regardless, it also recommends upgrading immediately to eliminate any related risk. It notes that on OpenSSL version 1.0.2 users are at risk from this flaw, although it has also released a crucial fix for all 1.0.1 users, meaning they should upgrade to that latest version, 1.0.1.r

Follows Freak, Heartbleed

OpenSSL was last in the "patch or perish" limelight in 2015 over the so-called Freak flaw - for "Factoring RSA-EXPORT Keys" - that could be used to forcibly downgrade crypto suites from using a "strong" RSA cipher to a weaker, "export-grade" RSA cipher vulnerable to being cracked.

Fresh Logjam Fix

OpenSSL on Jan. 28 also released a new fix for the so-called Logjam flaw, referring to yet another man-in-the-middle downgrade attack against TLS that can be used to force Diffie-Hellman crypto suites to use weak, 512-bit export-grade cryptography, which is vulnerable to being decrypted.

To get the fix, OpenSSL says version 1.0.2 users should upgrade to 1.0.2f, while version 1.0.1 users should upgrade to 1.0.1r.

The global security research team that uncovered the 20-year-old Logjam flaw last year warned that an "academic team" could break a 768-bit Diffie-Hellman prime, and they postulated that a nation state could break a 1,024-bit prime. The researchers said the flaw related to "weaknesses in how Diffie-Hellman key exchange has been deployed." At the time, they recommended that all OpenSSL users immediately upgrade to a new version that included a temporary fix that rejected all TLS handshakes that used Diffie-Hellman parameters shorter than 768 bits.

With the Jan. 28 update, however, OpenSSL can be set to reject any handshakes up to 1,024 bits, thus offering "stronger cryptographic assurance for all TLS connections using ephemeral Diffie-Hellman key exchange," the OpenSSL project says.

When Logjam was discovered, security experts also recommended that anyone using OpenSSH immediately upgrade because it relied on the OpenSSL libraries.

Thankfully, however, OpenSSH isn't vulnerable to the new OpenSSL flaw detailed on Jan. 28 because it never reuses Diffie-Hellman keys, says Damien Miller, an information security engineer at Google who works on the OpenSSH project.

FYI OpenSSH is unaffected by the OpenSSL SSL_OP_SINGLE_DH_USE bug - we never reuse DH values

After the Heartbleed fiasco, OpenSSH also added the ability to compile the crypto library without using any OpenSSL libraries. But even for implementations that do use it, Miller says the newly disclosed OpenSSL vulnerability poses no risk to OpenSSH users.

About the Author

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the Executive Editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, amongst other publications. He lives in Scotland.

Operation Success!

Risk Management Framework: Learn from NIST

From heightened risks to increased regulations, senior leaders at all levels are pressured to
improve their organizations' risk management capabilities. But no one is showing them how -
until now.

Learn the fundamentals of developing a risk management program from the man who wrote the book
on the topic: Ron Ross, computer scientist for the National Institute of Standards and
Technology. In an exclusive presentation, Ross, lead author of NIST Special Publication 800-37
- the bible of risk assessment and management - will share his unique insights on how to:

Understand the current cyber threats to all public and private sector organizations;

Develop a multi-tiered risk management approach built upon governance, processes and
information systems;