Mitigation of reported precomputed Diffie-Hellman prime vulnerabilities

UNCONFIRMED
Unassigned

Status

()

Core
Security
UNCONFIRMED
2 years ago
2 years ago

People

(Reporter: Jonas Thiem, Unassigned)

Tracking

44 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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?)

Updated

2 years ago
Group: firefox-core-security → core-security
Component: Untriaged → Security
Flags: needinfo?(ttaubert)
Flags: needinfo?(dkeeler)
Product: Firefox → Core

Updated

2 years ago
Group: core-security
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
Flags: needinfo?(ttaubert)
(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.
Flags: needinfo?(dkeeler)
(Reporter)

Comment 4

2 years ago
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

2 years ago
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
Duplicate of this bug: 1215844
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
You need to log in before you can comment on or make changes to this bug.