1215456 - Mitigation of reported precomputed Diffie-Hellman prime vulnerabilities

Status: RESOLVED DUPLICATE of bug 1496639

(Core :: Security: PSM, defect)

Description

[Jonas Thiem]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151013030225

Steps to reproduce:

Disclaimer: I'm not a cryptographer.

News reports indicate that precomputed DH primes are actively exploited for intruding into TLS connections:
http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/
Therefore, actions should be taken.

With my limited knowledge, I suggest something similar to the following:

Mitigation of exploitation through vulnerable target servers
-----------
(this might or might not be feasible depending on actual TLS protocol details I'm not aware of)

1.) Collect a list of commonly used primes in the major cryptographic libraries by inspecting their DH implementations

2.) Code this blacklist into Mozilla Firefox. At the minimum, this should prompt a "connection not secure" warning.

Mitigation of exploitation through Mozilla Products
-----------
* make sure that NSS no longer uses a fixed prime (if that isn't already the case)


If that approach isn't feasible, maybe fading out Diffie-Hellman entirely should be considered.

Comment 1

[Jonas Thiem]

I suggest this bug is made public since the news is already public as well. (Not much would be gained from hiding it at this point, right?)

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Just my own quick thoughts:

(In reply to Jonas Thiem from comment #0)
> 1.) Collect a list of commonly used primes in the major cryptographic
> libraries by inspecting their DH implementations
> 
> 2.) Code this blacklist into Mozilla Firefox. At the minimum, this should
> prompt a "connection not secure" warning.

Even if we would decide to blacklist popular primes that we think the NSA has precomputed, I don't think this would actually buy that much. A valuable target will hopefully switch to 2048-bit DH params or ECDHE suites for clients that support it. Legacy clients are as usual a problem.

1024-bit primes were known to be weak for years, the question rather is: are 2048 bits still enough? Enforcing 1024-bit DH was already a lot of fun, I don't think that we could do the same again. We could flag connections with DH key exchanges <2048 bit as "weak" and show a warning in the URL bar.

> If that approach isn't feasible, maybe fading out Diffie-Hellman entirely
> should be considered.

I think that's already happening. Most folks suggest prioritizing ECDHE suites over DHE and with your own 2048-bit DH parameters you're probably fine for a while, even if you're a valuable target. You could as well regenerate the file automatically every X months/years.

Showing a "weak cipher" warning might be worthwhile but other than that the best way forward is probably educating server admins like we already do: https://wiki.mozilla.org/Security/Server_Side_TLS

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Tim Taubert [:ttaubert] from comment #2)
> Enforcing 1024-bit DH was already a lot of fun, I
> don't think that we could do the same again.

Yeah, unless the entire ecosystem blacklists the suspected compromised params, we probably shouldn't go that route.

All in all, I'm not sure there are any useful steps we can take here now.

Comment 4

[Jonas Thiem]

Just having a warning symbol or something for the most common and suspected compromised ones would already be great. Anything better than nothing would improve the situation really

Comment 5

[rugk]

What about adding a about:config switch for DH key length so you can adjust this?

To prevent unintended modifications of this setting you may only allow the key to be adjustable >= 1024bit so you can't weaken your TLS connections.

Alternatively (or better: Additionally) it would be great if addons could access the DH key size so that they can do something. I've created a separate issue for this: bug 1215996

Comment 7

[Masatoshi Kimura [:emk]]

We should consider to disable DHE even if it will increase the usage rate of non-PFS cipher suites transiently.
- In theory, DHE will provide PFS. In practice, most servers will never update the DHE key.
- We have no way to negotiate the DHE key length.
- It is inconsistent that we treat 1024-bit RSA as insecure while we allow 1024-bit DHE key.
- It will fix not only this bug but also compatibility problems such as bug 1180526.
Chrome folks are also considering this: https://code.google.com/p/chromium/issues/detail?id=538690

Comment 8

[timeless]

Fwiw none of the current versions of Safari, Chrome, Edge, and IE accept dh1024 using https://dh1024.badssl.com/ for testing.

Comment 9

[ht16cq+b33nskirkppis]

Has this bug been forgotten about? It is a very serious security issue that all other browsers have fixed many years ago.

Comment 10

[:Gijs (he/him)]

(In reply to trumopudre from comment #9)
> Has this bug been forgotten about? It is a very serious security issue that
> all other browsers have fixed many years ago.

Paul/Dana, can you check?

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I imagine we'll fix this by just disabling DHE.

Comment 12

[Conan Chiles]

Hi,
Just following up on this one. Seems Firefox is the only major browser supporting dh1024 still

Comment 13

[ht16cq+b33nskirkppis]

Please reopen this bug.

Fixing precomputed Diffie-Hellman prime vulnerabilities should happen because it does not look like Firefox will disable DHE completely any time soon.