'Logjam' Vulnerability Threatens Encrypted Connections

An anonymous reader writes: A team of security researchers has revealed a new encryption vulnerability called 'Logjam,' which is the result of a flaw in the TLS protocol used to create encrypted connections. It affects servers supporting the Diffie-Hellman key exchange, and it's caused by export restrictions mandated by the U.S. government during the Clinton administration. "Attackers with the ability to monitor the connection between an end user and a Diffie-Hellman-enabled server that supports the export cipher can inject a special payload into the traffic that downgrades encrypted connections to use extremely weak 512-bit key material. Using precomputed data prepared ahead of time, the attackers can then deduce the encryption key negotiated between the two parties."

Internet Explorer is the only browser yet updated to block such an attack — patches for Chrome, Firefox, and Safari are expected soon. The researchers add, "Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency's attacks on VPNs are consistent with having achieved such a break." Here is their full technical report (PDF).

Comments

Internet Explorer is the only browser yet updated

[Anonymous Coward]

Really? The online JS test tells me my Iceweasel 38.0.1 isn't vulnerable.

"Good News! Your browser is safe against the Logjam attack. "

Root cause = speed over security

[xxxJonBoyxxx]

From TFA: "Generating primes with special properties can be computationally burdensome, so many implementations use fixed or standardized Diffie-Hellman parameters. "

Yeesh.

Re:Root cause = speed over security

[dwheeler]

Don't even ask. On the initial start-up, start calculating those new keys. You want the DEFAULT to be secure.

Re:Root cause = speed over security

[sexconker]

The root cause is people shouting "Don't roll your own crypto!" and scaring people away from using anything but the bog-standard, NSA-approved shit.

Re:Root cause = speed over security

[Dagger2]

It takes my (2009 era) machine 5-300 minutes (it varies wildly depending on how lucky you get) to generate a set of 4096-bit DH parameters. And that's actual CPU time, not "sitting around waiting for the Linux entropy pool to regenerate" time. You're going to have to make some tradeoffs here.

Re:Root cause = speed over security

[HiThere]

OTOH, using "roll your own crypto" is nortorious for individualized holes and weaknesses. It does tend to mean that the "one size fits all" means of breaking the code won't work, however. Or at least may well not work.

That said, if you have good enough communication to share custom crypto programs, you may be better off using a one-time pad....as that can't even theoretically be broken. But it does require a good source of random numbers (e.g. amplified triode vacum tube with no input so you're just amplifying noise). Such things are reasonably easy to build, but for some reason they aren't normal computer accessories. (Video cams watching a flickering flame are another good source.)

But custom crypto is hard to do correctly. AND it requires good communications to standardize the programs. So if you have the communication, a one time pad is better.

Re:Root cause = speed over security

[Dagger2]

So... generating new DH parameters on each connection leads to connection latencies of up to a few hours, which isn't really viable?

Also, what are you trying to protect against by regenerating the key frequently? We normally cycle RSA keys every year or two because of the risk that someone might break into the server in that time and steal the key (and we don't want the stolen key to be valid forever), but that's not an issue with DH parameters because they're public anyway.

The other reason to regenerate frequently is to limit the window of opportunity for brute force attacks, but that doesn't make much sense either: instead of generating lots of small keys, just generate one bigger key in the first place. It'll take far less CPU time and yet still be far harder to brute force.

Re:Root cause = speed over security

[suutar]

if they can't understand the difference between writing their own code and generating their own random numbers they're better off doing neither.

Re:Root cause = speed over security

[thogard]

There are things that can be done and things that shouldn't. For example there is a byte table of sines in MD5 that help scramble bits. If you scramble that table at all then you have a hash that is as strong as MD5 but unique as if someone tacks on a 2^2048 extra seed. It also keeps off the shelf hardware from trying your hash.

If you do the same thing with the DES S-boxes you can end up with a cryto that is so weak you might be able to decrypt it by inspection.

Re:Root cause = speed over security

[TheCarp]

>The other reason to regenerate frequently is to limit the window of opportunity for brute force attacks, but that doesn't make much sense either:

Lets not lose sight of the fact that, even doing it only once EVER, even if you then redistribute that result to every future machine you build, is already far better than the status quo.

The current standard appears to be "use the same default ones distributed to everyone else". So really even "each unique machine generates a new set once" is a massive improvement and downgrade to the usefulness of breaking any given prime.

Re:Root cause = speed over security

[Dagger2]

It is, but you'd achieve a much higher resistance to precalculation attacks just by generating and sharing a longer key in the first place -- which also has the advantage of not burning hours of CPU time on every single machine.

Perhaps the best thing to do here would be for each system to download DH parameters (or get them from a package or whatever) at installation time, and then regularly change the parameters that are available for download. That avoids the massive generation time on each machine, but also limits the amount of machines that you share parameters with. So long as those parameters aren't tiny, that should be fine.

Bonus points if you include a simple "make_me_my_own_dhparams" script that makes generating your own parameters trivial, but I do think we can get most of the benefit here without requiring every single install to use it.

And that is why you do not downgrade encryption...

[gweihir]

At the time these utterly stupid laws were made, these ciphers where still somewhat secure against most attackers. The problem is that encryption software and parameters can stay in use for a long time.

Big Question

[currently_awake]

Did this flaw come into existance due to lazy programmers trying to save run time, or did the NSA install this as a back door? How badly has the NSA sabotauged the border defences of the USA?

Re:Big Question

[FranTaylor]

How badly has the NSA sabotauged the border defences of the USA?

They have sabotauged your ability to spell!

Re:Big Question

[StikyPad]

You'll shut me down with a push of your button?

Re:Big Question

[gizmo2199]

I'm out, and I'm gone!

So im guessing it doesn't fix the cable?

[Anonymous Coward]

oblig.

downgrade attacks...

[nimbius]

caused by export restrictions mandated by the U.S. government during the Clinton administration.

So this assertion arrives at one of two uncomfortable conclusions.
1. US intelligence agencies have had the ability to exploit this for more than a decade
2. US intelligence agencies, having understood advances in computing to be inevitable, carved a backdoor and did some wishful thinking.

Either way the internet is starting to realize not all well-intentioned backward compatibility that also includes an unfortunate downgrade in security is done in altruistic or neutral capacity. Shell companies and paid researchers can and have in the past intentionally rendered well constructed algorythms and crypto effectively optional in the name of compatibility and their product. Ephemeral ECC for example, although cited by reseachers as a means to avoid this kind of attack, is suspect. The NIST elliptic curves have now been tainted by Snowdens revelations as well. the SSH 2 implementation of the 25519 curve, by Aris of the libssh project, attempts to address the problem of divergences in elliptic-curve cryptography by proposing a safer alternative that doesnâ(TM)t implement the mysterious constants common among other schemes.

Re:downgrade attacks...

[Creepy]

It actually has more to do with export law - in fact, Clinton's Executive Order transferred control of encryption from the Munition List to the Commerce Control List. Prior to the Clinton updates, the maximum exportable encryption was 40 bits. Part of the reason the change got Clinton's attention is the PGP investigation, where the creator of PGP exported the computer code in a hardback book (free speech) as opposed to in a computer (munitions), allowing it to be scanned and compiled outside of the US. Also the weak foreign encryption export limits were starting to hurt US businesses (mine included at the time - we outsourced all encryption work and worldwide distribution to England, leading to about 20 US workers losing their jobs).

Re:Bunny Lebowski

[Shortguy881]

He must be here to fix the cable.

I tested my browsers ...

[CaptainDork]

... and here's the breakdown:

IE and Safari test OK.

Firefox, Chrome, and Opera fail the test.

--

That's on my HP desktop at home.

Re:Certificate authorities surely?

[petermgreen]

There have been a couple of recent developments which attempt to fight back against the "CA coercion" vulnerability.

One is "http key pinning", that way your browser is still trusting the public CA network for the initial connection to a site but after that it additionally checks a list of keys provided by the site (the site has the option of whether to declare trust in a CA or whether to approve individual keys). This will make it very difficult for a MITM with a coerced key to operate in secret, if the user ever uses an internet connection the MITM doesn't control and then comes back to the one controlled by the MITM then they will notice the interference.

Another is "certificate transparency" which if enforced means a CA can't issue certs without publishing the fact they are doing so. This is a bit of a longer term goal, it will be some time if ever before clients can force this model on all CAs but again it will make it much easier to discover MITM attacks.

...unless you rule Australia

[tepples]

Yet Australia wants to return to "export-grade" encryption.

Re:...unless you rule Australia

[gweihir]

The Australians will either come to their senses of find themselves squarely in the second world in the long run. Some researchers already left the country and a lot more will be thinking about it. It will be interesting to see what will happen.

However, if recent history is any indication, Australians like to get screwed over by their government, hence they keep voting for anti-citizen politicians. Must be some kind of collective masochism going on down under.

Re:...unless you rule Australia

[_merlin]

However, if recent history is any indication, Australians like to get screwed over by their government, hence they keep voting for anti-citizen politicians. Must be some kind of collective masochism going on down under.

All our major political parties (Liberal/National, Labor and Green) have anti-citizen policies. Much like the US Republicrat system, while you can choose who's going to be fucking you, you'll still have to bend over.

Now the Mad Men finale makes sense...

[alexjplant]

Don Draper is busy writing copy for these vulnerabilities. Seriously, why are pathetic neckbeards the world over so obsessed with making these cute vulnerability names and logos? Since when did a security vulnerability need branding? I guess a CVE ID is unwieldly but when will the madness end? Is the next one going to be called FailPwn1012?

Re:Now the Mad Men finale makes sense...

[Zaurus]

Worse than branding...there doesn't seem to be a CVE assigned to this at all. Has anyone found one?

Competitive Disadvantage

[Archtech]

How long before legislators and the White House understand that this kind of restrictive export law simply handicaps US researchers and corporations? Competitors from other nations such as India and Russia get a significant advantage over their opposite numbers in the, er, Land of the Free.

Logjammin

[captjc]

"Hello, meine dispatcher says there eez somezing wrong mit deine Encrypted Connections?"

"Yeah, come on in. I'm not really sure exactly what's really wrong with the cable."

"That's why they sent me, I am an expert."

Some explanation, and what OpenSSL is doing

[rich_salz]

Emilia from the OpenSSL team just published a good blog post that explains some of the "twists" of logjam, and also what OpenSSL is doing about it. It's here: http://openssl.org/blog/blog/2...

Wrong on one thing

[kgroombr]

The Clinton Adminstration couldn't have been responsible for this cause it was Bush's fault.

Primes

[wonkey_monkey]

Breaking the single, most common 1024-bit prime used by web servers

Well that's silly. They should try using different primes for a start.

"weapons grade encryption"

[green1]

Encryption is a defensive technology, not a weapon.

I can't see any good reason (plenty of bad ones!) for ever limiting defensive technologies. Weapons are a different matter because they can cause direct harm to others, but a shield, or armour, or encryption, are all defense only with no offensive angle. They should never be limited.

Re:"weapons grade encryption"

[mongothesecond]

Defensive technologies also enable combatants, sometimes more than a particular offensive technology.

Re:"weapons grade encryption"

[green1]

But they do far more to protect the innocent than they are capable of doing to assist an enemy.

As long as governments continue to see innocents as the enemy, we have all lost.

Opportunity to detect MITM attacks?

[Ungrounded Lightning]

I skimmed the start of the paper. If I have this right:

  - Essentially all the currently-deployed web servers and modern browsers have the new, much better, encryption.
  - Many current web servers and modern browsers support talking to legacy counterparts that only have the older, "export-grade", crypto, which this attack breaks handily.
  - Such a server/browser pair can be convinced, by a man-in-the-middle who can modify traffic (or perhaps an eavesdropper-in-the-middle who can also inject forged packets) to agree to use the broken crypto - each being fooled into thinking the broken legacy method is the best that's available.
  - When this happens, the browser doesn't mention it - and indicates the connection is secure.

Then they go on to comment that the characteristics of the NSA programs leaked by Snowden look like the NSA already had the paper's crack, or an equivalent, and have been using it regularly for years.

But, with a browser and a web server capable of better encryption technologies, forcing them down to export-grade LEAKS INFORMATION TO THEM that they're being monitored.

So IMHO, rather than JUST disabling the weak crypto, a nice browser feature would be the option for it to pretend it is unpatched and fooled, but put up a BIG, OBVIOUS, indication (like a watermark overlay) that the attack is happening (or it connected to an ancient, vulnerable, server):
  - If only a handful of web sites trip the alarm, either they're using obsolete servers that need upgrading, or their traffic is being monitored by NSA or other spooks.
  - If essentially ALL web sites trip the alarm, the browser user is being monitored by the NSA or other spooks.

The "tap detector" of fictional spy adventures becomes real, at least against this attack.

With this feature, a user under surveillance - by his country's spooks or internal security apparatus, other countries' spooks, identity thieves, corporate espionage operations, or what-have-you, could know he's being monitored, keep quiet about it, lie low for a while and/or find other channels for communication, appear to be squeaky-clean, and waste the tapper's time and resources for months.

Meanwhile, the NSA, or any other spy operation with this capability, would risk exposure to the surveilled time it uses it. A "silent alarm" when this capability is used could do more to rein in improper general surveillance than any amount of legislation and court decisions.

With open source browsers it should be possible to write a plugin to do this. So we need not wait for the browser maintainers to "fix the problem", and government interference with browser providers will fail. This can be done by ANYBODY with the tech savvy to build such a plugin. (Then, if they distribute it, we get into another spy-vs-spy game of "is this plugin really that function, or a sucker trap that does tapping while it purports to detect tapping?" Oops! The source is open...)

Re:Internet Explorer is the only browser yet updat

[aaarrrgggh]

Mobile Safari, and the Apple Watch OS were updated yesterday.

Random observations

[WaffleMonster]

NSA owning VPNs is not surprising given pathetic state of VPN technology as currently deployed. Widespread use of group keys, PPTP and challenge response authentication. A tragedy of nonsense NSA would have to be negligently incompetent to not take full advantage of.

It isn't like this is a big secret or that people don't know better. The bells have been ringing for years ... dare I say decades in some cases yet many in a position to know better simply don't care.

What is interesting to me distance between EC and RSA in terms of relative key size vs security seems to be shrinking by quite a lot.

Honestly I never put much stock in differences between precomputation vs having to start over.
  I know practically it makes it a lot easier to do a lot of damage but from my perspective if you have the resources to pull off something just once even if that effort can't be reused the technology has already failed.

I have not been able to quite figure out what they meant when they said TLS is broken. I understand the part of being able to negotiate parameters with a TLS extension yet at the end of the day if you are able to break lowest common denominator crypto so bad you can compromise handshake then secure negotiation must also cease to be secure.

Re:Internet Explorer is the only browser yet updat

[gizmo2199]

Android was updated... Nevermind I can't afford a new phone.

Re:Breaking the single, most common 1024-bit prime

[andyhhp]

The calculation to generate new primes is expensive (and in the past, was prohibitively so). As the prime numbers in DH are public (they are in the clear as part of the handshake), it was decided that using the same set of everything was a GoodIdea(tm).

This is not the case in reality, as a one-off week of cloud resource provides an attacker with sufficient data to decrypt the stream in realtime.