Logjam TLS vulnerability is academic, not catastrophic

Paco Hope asserts that it is inexcusable to support or enable "export-grade" cryptography. The Logjam security flaw, like FREAK before it, drives this point home.

Image: iStock

Logjam is a new weakness in TLS that allows an attacker to downgrade the cryptography on a connection; it is similar to another recent attack on TLS called FREAK. To help us understand why widespread panic is unnecessary, let's look at what a practical attack would get the attacker, and what that attack would require.

What an attacker could get

An attacker leveraging Logjam could see all the data that the victim thought was protected by TLS.

TLS protects virtually all network connections: VPN systems, online shopping, server-to-server communications, etc. Often we trust online shopping sites or network endpoints because we believe TLS is protecting the data as it passes from point A to point B. Without TLS, logging in on the internet would be like shouting your password across a crowded office.

What an attack would require

It takes a lot to mount a practical attack that hinges on Logjam (think: more computing power than the NSA or a major university lab).

1. The attacker must be actively listening to the conversation before it starts -- lurking on an airport Wi-Fi near the victim is an example. The attacker must select a victim in advance and actively manipulate the victim's connection. He cannot vacuum up all the data today and find a victim in it next week.

2. Both the victim and the victim's online service must use traditional Diffie-Helman key exchange and "export-grade" ciphers.

3. The attacker must be a man-in-the middle on the conversation. The attacker must be in between the victim and the victim's internet connection already or able to insert themselves once the conversation has started.

4. The attacker needs to spend some time and crypto power in advance to precompute values based off of commonly used 512-bit prime numbers. Or, they need access to a list of precomputed values for the primes that the client will choose.

What is threatened

VPNs are an ideal target for Logjam. An attacker can target a hotel lobby where people are connecting back to their offices via VPN. The connections are long-lived and carry sensitive information, making them worth the trouble.

Logjam is less threatening for online shopping (e.g., credit card numbers); the attacker must tamper with every connection he wants to see and force it to downgrade. There are too many HTTPS connections in a typical online shopping session to interfere with them all and look later to see what you captured. There aren't enough credit card numbers, userids, or passwords per tampered stream of data to make it worthwhile.

The main data an attacker would get from a VPN connection is whatever data she could get if there was no crypto. Internal email, internal web page content, phone numbers, email addresses, appointments, names, and so on will all be in the clear.

If the victim is using TLS with an internal system, even though they are connected via the VPN, the attack will probably fail. The attacker would have to detect and tamper with that TLS connection via more man-in-the-middle stuff inside the VPN connection they're already attacking.

The attacker sees later what the victim saw at the time. It may or may not give access that the attacker can use later; for instance, it might give a userid and password to the internal system. That is big deal, but even then there may be some multi-factor authentication, some intrusion detection, or some other security controls that will give the victim's infrastructure a chance to detect, delay, or prevent abuse of the stolen credentials.

What enterprises should do

At the end of the day, it is sufficient to disable export-grade cryptography everywhere it can be disabled. Clients (i.e., users) are not vulnerable if the server refuses to downgrade to export-grade ciphers. That's the long and short of it: disabling export-grade cryptography eliminates Logjam and many other issues.

Keep calm and build secure software

Most websites, online services, embedded devices, and other software suffer from rookie mistakes; the IEEE's top 10 ways to avoid security flaws and the OWASP's Top Ten lists highlight those mistakes. Most organisations should focus on the basics of building software securely.

At the end of the day, we need to kill off export-grade cryptography -- its protections are weak enough that they can be broken through brute force, and we disable it in our browsers, our VPN clients, our email clients, and all of our servers. Having disabled export-grade cryptography, though, we are done. We can get back to securing our systems against less exotic attacks.

Attackers will resort to a Logjam style attack only if it's their best option. Firms and individuals that worry about nation-state attacks, like the NSA and GCHQ, will probably already be protected as a side effect of something else they do. Organisations that are not already worried about nation-state attackers should stay the course and continue to work on making their apps secure from the beginning, through secure user stories, designs, and architecture.

Also see

Note: TechRepublic, ZDNet, and Tech Pro Research are CBS Interactive properties.

Visit TechRepublic