The Logjam vulnerability is a security threat that affects the Diffie-Hellman key exchange using 512- to 1024-bit keys. In essence, the threat downgrades the Transport Layer Security (TLS) connection and exploits a weakness caused by using the same prime numbers in the encryption to execute a Man-in-the-Middle attack.
Until the official discovery of the threat, computer researchers had known that the 512-bit Diffie-Hellman was not strong enough for modern encryption needs. They have been aware of the potential weaknesses since 1992. However, the seriousness of the vulnerability was not fully recognized until 2015, when a large group of scientists demonstrated different ways in which the Logjam vulnerability can be used for malicious purposes.
What Is the Logjam Vulnerability?
The Logjam attack can be executed on Diffie-Hellman cipher suites. They constitute a commonly used cryptographic algorithm, known as forward-secure crypto, which enables protocols to establish a secure connection after setting a shared key. The Diffie-Hellman key exchange is central to many protocols, including those that use RLS and HTTPS, SSH, IPsec, and SMTPS.
The Logjam vulnerability resembles the previously discovered FREAK attack. It’s also related to the term ‘export cryptography’ introduced in the 1990s due to U.S. restrictions on software export. Strong cryptography was not allowed for some export products, resulting in many weak encryption implementations that are still around today.
However, Logjam is not caused by an implementation vulnerability but by a TLS protocol weakness. The other difference is that the affected key exchange with Logjam is a Diffie-Hellman rather than an RSA.
How Does the Logjam Vulnerability Work?
The Logjam threat forces the TLS connection downgrade from non-DHE_EXPORT to a DHE_EXPORT. This allows a malicious user to access and inject harmful data into the connection, practically attacking the 512-bit Diffie-Hellman protocol group. This is, in essence, a Man-in-the-Middle attack that exploits the weakness of 512-bit export-grade cryptography. In addition to eavesdropping and manipulating data, a malicious user may also decrypt old sessions set with the same parameters.
The security of the Diffie-Hellman key exchange is based on how complex it is to solve the discrete logarithm problem. Unfortunately, the algorithm uses the same pre-generated prime numbers in most cases, which makes it easier and cheaper to crack such encryption. With the help of a one-time computation, the discrete algorithm can be broken. Researchers found that it would take only 100,000 CPU core hours as an investment of time needed to do so.
The Logjam attack, as noted, is also related to the weaker export cipher suites. Connections to servers that use them for encryption are vulnerable despite having more robust Diffie-Hellman parameters. An active Man-in-the-Middle attacker can access the export-grade Diffie-Hellman parameters and crack them. Then they can use them to take over client connections.
In addition, the majority of servers use the same built-in Diffie-Hellman parameters. Researchers have thus theorized that an attacker can use the complex and expensive precomputation for cracking one server on numerous servers.
Discovery of the Vulnerability
Already in 1992, computer researchers were aware of the security vulnerability. Still, a large portion of the worldwide data traffic uses exactly Diffie-Hellman groups that are smaller or equal to 1024 bits.
The Logjam threat was officially discovered in May 2015 by computer scientists at CNRS, INRIA, Microsoft Research, Johns Hopkins University, University of Michigan, and University of Pennsylvania. David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann.
In October 2015, the group of researchers published their paper Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, which won the Best Paper Award at the 22nd ACM Conference on Computer and Communications Security (CCS ’15) in Denver, Colorado.
The Logjam vulnerability threatens websites, mail servers, and other services using TLS that support DHE_EXPORT ciphers.
At first, it was assessed that 8.4% of the top 1 million domains and 3.4% of browser-trusted sites were vulnerable among those using the HTTPS protocol.
OpenSSL increased the minimum Diffie-Hellman key size to 768 bits right after discovering the vulnerability, with their immediately following release. Then they went further to 1024 bits. OpenSSL also strengthened its cryptographic defaults to secure server configuration for Diffie-Hellman cipher suites. As a result, updated OpenSSL-based clients can be deemed protected from Logjam.
The most common and widely used browsers, including Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari, introduced updates that address the Logjam attack.
Logjam Attack Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
How to Prevent Logjam Vulnerabilities
To counteract the Logjam vulnerability, you must make sure that you use only strong cipher suites and avoid weak primes.
In particular, you should check that TLS libraries are updated and that servers use 2048-bit or larger primes. Clients have to be set to reject Diffie-Hellman primes of less than 1024-bit.
You have to disable support for export cipher suites for web and mail servers and use a 2048-bit Diffie-Hellman group. For SSH, server and client installations need to have the updated version of OpenSSH that uses Elliptic-Curve Diffie-Hellman Key Exchange.
As for general users, it’s recommended to keep web browsers always updated. This is because the popular browsers always release fixes for significant threats regularly.
You can review our guide on Secure TLS Configuration for further instructions on determining the correct settings.
Are your systems protected against Logjam vulnerability? Use the robust Crashtest Security’s Vulnerability Testing Software to determine your data’s safety.