Logjam Encryption Flaw Threatens Secure Communications On WebLogjam Encryption Flaw Threatens Secure Communications On Web
Most major browsers, websites that support export ciphers impacted
May 20, 2015
More than 80,000 of the top 1 million HTTPS domains on the Internet are vulnerable to a bug in the basic design of the Transport Layer Security (TLS) protocol that is used to encrypt communications between browser clients and web servers.
The new Logjam flaw is similar to the recently discovered Factoring attack on RSA-Export Keys (FREAK) flaw in that it gives attackers a way to get web servers and browsers to use weaker encryption keys than they normally use when communicating with each other.
Such downgrades can allow attackers to intercept and read the contents of supposedly secure communications in clear text. According to the security researchers who discovered Logjam, it is quite likely that the U.S. National Security Agency (NSA) exploited the flaw to attack and snoop on VPN-protected communications around the world.
A website created by the research team that discovered the vulnerability states that Logjam affects all modern browsers, as well as websites, mail servers, and TLS-dependent services that still support 512-bit export-grade ciphers. While it is similar in effect to FREAK, Logjam is not an implementation flaw, but a flaw in the actual TLS protocol itself.
Computer scientists at Inria, a French public research institution, Johns Hopkins University, Microsoft Research, the University of Michigan, and the University of Pennsylvania discovered Logjam several months ago and have been working with various client and server software developers to mitigate the threat.
Microsoft, Mozilla, and Google have all updated their browsers, and OpenSSL and Apple are expected to do the same soon, according to the researchers. On the server side, organizations such as Apache, Oracle, IBM, Cisco, and various hosting providers have been informed of the issue. Several TLS developers plan to support a new extension that will mitigate the risk of forced encryption protocol downgrades.
At the center of the Logjam problem is the continued support for weak 512-bit export ciphers by numerous websites and modern browsers. Back in the 1990’s, U.S. government concerns over other countries having access to strong encryption technologies meant that most of the software shipped abroad by American technology firms supported only 512-bit encryption keys.
U.S. technology companies using strong encryption tools, however, included support in their products for 512-bit keys in order to maintain backwards compatibility with products being used overseas.
The encryption restriction itself is long gone. But many commonly used technologies on the net still include support for 512-bit encryption, though much stronger cryptographic protocols are available currently.
The Logjam flaw basically takes advantage of this fact to trick web browsers and servers into using the weaker—and consequently more easily compromised -- encryption standard when communicating with each other. Though the client browser and server might be capable of supporting strong encryption, the TLS flaw gets them to use the 512-bit encryption, while making the browser believe it is using strong encryption.
“The crux of the issue here is the use of DHE_EXPORT ciphers, which uses shorter, 512-bit keying material for the Diffie-Hellman key exchange than what is normally supported and recommended today,” said Tod Beardsley, security engineering manager at Rapid7.
“While normal secure browsing will not use these ciphers by default, they are still supported by all browsers, with the notable exception of Internet Explorer, and offered by a fraction of the top one million websites,” he says.
A man-in-the-middle attacker can get a browser to use the export-grade cipher and then snoop in on the communications. Cybercriminals sitting in a coffee shop with a WiFi network, would potentially be able to snoop on what others on the same network are doing, and so too would state-sponsored groups, he noted.
“While Logjam is usually discussed as a browser and web server attack, there are other protocols that support DH key exchanges,” he said. These include e-mail protocols, such as secure versions of POP3, IMAP, and SMTP, and also SSH, and IPSec-based VPNs. “Clients that use these protocols also need patches to no longer support the weak key exchange, and servers need patches to no longer offer them.”
Another issue related to Logjam is that millions of HTTPS, SSH, and VPN servers all use the same set of prime numbers for exchanging keys during the initial handshake between a client browser and web server, the researchers noted in their paper. This makes it easier to break the keys, especially for those with the resources to do so, they noted.
For instance, by using a specific encryption-breaking algorithm against the most common 512-bit prime numbers used for TLS, the researchers said they were able to demonstrate that the Logjam attack could be used to downgrade connections to 80 percent of TLS servers that support export ciphers.
The researchers estimated that any academic team with average resources could break a 768-bit prime and that a nation-state could break a 1024-bit prime number used in Diffie-Hellman key exchanges. “Breaking the single most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18 percent of the Top 1 Million HTTPS domains,” they warned. Breaking a second prime would allow passive decryption of connections to 66 percent of VPN servers.
About the Author(s)
You May Also Like
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
What's In Your Cloud?Nov 30, 2023
Everything You Need to Know About DNS AttacksNov 30, 2023
9 Traits You Need to Succeed as a Cybersecurity Leader
The Ultimate Guide to the CISSP
AI in Cybersecurity: Using artificial intelligence to mitigate emerging security risks
Quantifying the Gap Between Perceived Security and Comprehensive MITRE ATT&CK Coverage
5 Reasons To Move your PKI Deployment to the Cloud