Encryption & Key Management , Next-Generation Technologies & Secure Development , Security Operations

OpenSSL Flaw Enables HTTPS Decryption

New Fix Includes Improved Logjam Defenses Too
OpenSSL Flaw Enables HTTPS Decryption

All users of the OpenSSL crypto library should upgrade immediately to eliminate a serious flaw that attackers could exploit to decrypt Web traffic, security experts warn.

See Also: Is Cyberstorage the New Paradigm for Data Security?

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.

That followed warnings in 2014 over the critical OpenSSL Heartbleed flaw, relating to the use of Diffie-Hellman (see Heartbleed Alert: Vulnerability Persists). On the upside, the discovery of the vulnerability led many organizations to pledge funding for the open source projects that underpin so much of today's Internet (see OpenSSL Gets Funding After Heartbleed).

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.

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

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

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, among other publications. He lives in Scotland.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.