Software Integrity Blog


Why you fix Logjam later

The Internet is buzzing with talk of “Logjam,” a vulnerability in Diffie-Hellman key exchange that allows us to downgrade the cryptography on a connection to something practical to decrypt. An attack leveraging Logjam would be able to see in the clear all the communications that the user thought were encrypted. This issue should be a non-event for most organizations. Let’s take a look at why you should keep calm and build security in.

A practical logjam attack

If you are not a nation-state or major university researcher, you will need to meet a few requirements to mount an attack using Logjam. Many of these requirements are not trivial.

  1. You must be in place and ready to attack before the connection starts. This usually means being physically close to one of the endpoints. Lurking in a cyber café on the same WiFi as your victim is a classic example.
  2. You have to select one or more specific victims in advance. You can’t hoover up all the data now and select victims later. You can attack as many victims as you have computing capability, but you have to actually attack them when they start their connections.
  3. Both the victim’s client software (e.g., browser) and the server must support traditional Diffie-Hellman key exchange and must support “export-grade” cipher suites.
  4. You must be able to effectively man-in-the-middle the conversation. Typically you must be in between the victim and their Internet connection already.
  5. You have pre-computed parameters for the primes the server will choose. Like many rainbow tables for password hashes today, there may soon be lookup tables for RSA primes in circulation. For now, attackers must compute their own. Also like rainbow tables, we are confident that many “normal” people (not nation-states, not universities) have the computing horsepower to do this up to 512 bit primes in a reasonable amount of time.

What is threatened

Logjam is not a threat to an online store (e.g., getting many passwords and credit card numbers, etc) as much as it is a threat to individual shoppers. There are many HTTPS connections in a typical online shopping session. It is impractical to trick them all into downgrading in real time, capture them all, and look at what you captured. SSL session resumption does allow SSL to be resumed with old parameters on new connections. This can make a single Logjam attack slightly more effective. Individuals can be attacked this way, but only nation-states could target large numbers of users at a target site.

VPNs make a practical target for Logjam. A hotel lobby with lots of important people using VPNs on the WiFi is a “target rich environment.” You still have to single out victims, or be ready to man-in-the-middle many victims who you will learn about later. A VPN connection, though, is usually long-lived and carries sensitive data, making it worth the trouble to attack it.

The main data you get by attacking is the same data you could get if there was no cryptography protecting the connection. If the victim is using TLS to talk to his company’s internal systems while also using the VPN, the attacker is probably stuffed. You would have to detect and tamper with that TLS connection via more man-in-the-middle stuff inside the VPN you’re already man-in-the-middle attacking. But lots of data like internal email, internal web sites, phone numbers, email addresses, appointments, names, and so on will all be in the clear.

As an attacker, you only get access to things the victim does. It may or may not give you access of your own that you can use later. For example, you might get the user’s ID and password for an internal system. That does not give you, the attacker, the ability to get on the internal network, login, and do what you want. Having a user ID and password is huge, but it doesn’t necessarily cross the goal line. 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 data.

Stick to your knitting

While this is important for some people, it is not important for most people. Most websites, online services, embedded devices, and other software suffer from rookie mistakes. When the IEEE Center for Secure Design surveyed major software firms about the most prevalent and terrible problems in software design, their list was full of common goofs. But if your software suffers from plenty of the same things that most people’s software suffers from, let the operations folks handle this and keep focusing on the basics and building secure software.

Sadly, you will probably fix it this month

Logjam is an operational issue. It is fixable in a fairly straightforward way by twiddling a few parameters in the crypto. Cryptography is huge in everyone’s mind and we’re busy polishing the gigantic brass locks on our front door, while wind whistles through the curtains of our open windows. Most firms will push out a patch, change some VPN endpoint configurations, and maybe even deploy updated versions of VPN clients to their staff. That’s great, but we need to remain focused on building good software.

It is inexcusable to use or support “export grade cryptography” in any context any more.

Attackers will resort to a Logjam style attack only if it’s their best option. Sadly, this is rarely the best option today. Anyone who is worried about pedestrian attacks like credit card fraud can ignore this. Attackers of modern Internet-facing software and services will get plenty of results by looking for and exploiting things listed in the OWASP Top Ten. If you are already worried about nation-state attacks along the lines of the NSA and GCHQ, Logjam is probably not your most important worry. You probably are already protected as a side effect of some-thing else you’re doing to thwart the likes of the NSA. If you’re not already worried about nation-state attackers, you are better served focusing on building security in.


More by this author