New issue
Advanced search Search tips
Starred by 18 users

Issue metadata

Status: Fixed
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocked on:
issue 490260

Sign in to add a comment

Increase minimum DH size to 1024 bits (tracking bug)

Project Member Reported by, May 20 2015

Issue description

This is a tracking bug for addressing the ecosystem issues raised at not that it's public.

See for details.

Comment 1 by, May 20 2015

 Issue 483724  has been merged into this issue.

Comment 2 by, May 20 2015

agl@: Can you share your plans for how the deprecation will go (what UI changes, expected rate of broken sites, etc.)? Would like to help that go smoothly. If you can't share on the (public) bug, e-mail or talk in person on Thurs?
felt: The handshakes are just going to hard fail, no badging or anything. See for the error from the last time we did this. I'll let agl answer the question in full since I don't know the expected breakage numbers.

Looking at that error, we do need to fix the "Learn more" URL from the last time and update the page.

It should be:
Or perhaps this shorter one:

Comment 4 by, May 20 2015

felt: we already have a DH minimum size and sites that are under it get a fatal error. (See attached image.)

Microsoft did a security update last week to enforce a 1024-bit minimum and I believe that it also causes a fatal error.

Overall, it looks like about 0.3% of sites with a valid certificate chain will be affected by this.
32.7 KB View Download

Comment 5 by, May 20 2015

Blockedon: chromium:490260
Project Member

Comment 6 by, May 20 2015

The following revision refers to this bug:

commit a7997f12be358e58aeb2345bb8b88a9d53240024
Author: Adam Langley <>
Date: Fri May 15 00:38:50 2015

Set minimum DH group size to 1024 bits.

DH groups less than 1024 bits are clearly not very safe. Ideally servers
would switch to ECDHE because 1024 isn't great either, but this will
serve for the short term.

BUG= 490240 

Change-Id: Ic9aac714cdcdcbfae319b5eb1410675d3b903a69
Reviewed-by: David Benjamin <>
Reviewed-by: Adam Langley <>


are DHE suites still going to be considered "modern", now that we know they don't really provide forward secrecy?

"Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections."

Comment 9 by, May 20 2015

Re #3: Good point about the "learn more" link. Do you know how to get the help center article updated? LMK if you need help with that.

Do we expect that this will cause a bunch of questions in the help forum? (My guess is yes.) If so it would be good to reach out to Melody with a short statement ready to go.
Project Member

Comment 10 by, May 20 2015

The following revision refers to this bug:

commit aa9abe7692a3ee99b69811594938d97cb180351e
Author: avi <>
Date: Wed May 20 20:57:17 2015

Use the correct URL for ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY errors.

BUG= 490260 , 490240 
TEST=as in bug

Review URL:

Cr-Commit-Position: refs/heads/master@{#330799}


Comment 11 by, May 20 2015

Re #10: I notice that these are all URLs. It might be helpful to have the help center folks actually write a HC article instead, if we think a non-trivial number of people are going to see this. (People search the help center.)

Comment 12 by, May 20 2015

felt: I've tweaked so that it's technically correct but, if you want to make it more human, please go ahead.

There will probably be comments on the help forum, although perhaps we can have Melody direct people to that same help page.
I've also added a link to that page from the deprecation section of the TLS FAQ:

What would you think of moving  entirely into the question, and perhaps moving the entire question into a separate page?
Project Member

Comment 14 by, May 20 2015

The following revision refers to this bug:

commit b1f400ca05a556848195154c2a5b2f7c15063fd4
Author: agl <>
Date: Wed May 20 22:59:42 2015

Roll third_party/boringssl/src 96600327:a7997f12

Summary of changes available at:

This pulls in the 1024-bit minimum DH group size restriction.

BUG= 490240 

Review URL:

Cr-Commit-Position: refs/heads/master@{#330828}


Comment 15 by, May 21 2015

Status: Fixed
lgarron: thanks for adding the link. I'm not sure that I follow you however: surely that "question" is already on a separate page—the page that we're talking about.
I meant: Move info DHE into the TLS FAQ deprecation section (instead of a dedicated DHE page).
And maybe: Move the TLS FAQ deprecation section (four-ish topics) to its own page.

I don't think moving the DHE into the TLS FAQ will help, at least not unless/until there's an HC article.

Moving the TLS FAQ out into its own page I'm neutral on. There have been separate attempts to both consolidate pages and to split pages up, so there are strong opinions on either side historically. Unless you have a strong opinion, it may be better to let inertia carry there.
Alright, status quo sounds fine to me.
(I mainly want to keep having a places lists all the current deprecations. As long as we mention DHE there, I don't really care if we link to a separate explanation.)
Labels: M-45
 Issue 492159  has been merged into this issue.
I have installed stable version of Chrome:

Google Chrome	43.0.2357.81 (Official Build) m (32-bit)
Revision	f873f0128382b8cf6b5c2a877d12491ca807748e-refs/branch-heads/2357@{#434}

When can I expect this fix in stable channel? The site reports that: "Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser."


Comment 22 by, Jun 8 2015

This change is on track for Chrome 45 at the moment.
This change is a great litmus test to detect unfortunate servers that use 768-bit DH in 2015, including electronic payment services and ISP billings.

300 KB View Download DH768.png
432 KB View Download
Project Member

Comment 24 by, Jun 9 2015

The following revision refers to this bug:

commit 93937caf120fed43de182e475822805afdbe3001
Author: mostynb <>
Date: Tue Jun 09 19:36:17 2015

increase crypto_unittest key sizes to satisfy NSS 3.19.1

NSS version 3.19.1 added minimum key size constraints to avoid the Logjam attack:

> The minimum size of keys that NSS will generate has been raised:
>    The minimum modulus size for RSA keys is now 512 bits
>    The minimum modulus size for DSA keys is now 1023 bits
>    The minimum modulus size for Diffie-Hellman keys is now 1023 bits

BUG= 490240 

Review URL:

Cr-Commit-Position: refs/heads/master@{#333554}


NSS 3.19.2 reverted the change to the the minimum required key sizes so Chromium built against system NSS is now reported as vulnerable again. [1]

Is there a way to correct this?

No it didn't. It just moved where the changes are to only affect TLS clients, rather than all consumers.
You are correct, the relevant NSS commit is:

The minimum key size is now enforced in libssl3 which Chromium doesn't seem to use. (This also explains why Firefox (which uses libssl3) is not reported as vulnerable by
As noted in this bug, that change is being rolled out with Chrome 45, so it is not tied to your system NSS version.
My mistake, I assumed that Chromium didn't use BoringSSL on Linux; guess I was confused by the patch to the bundled NSS in comment 8. I just tested Chromium 45.0.2431.0 and it is safe against Logjam (according to

Sorry for the noise! :)
(We don't use BoringSSL on Linux (yet!), but we ship a bundled copy of NSS's SSL implementation. Chrome 45 includes the change to both stacks.)
Thank you for the information, it's starting to make sense now.

From what I understand, Chromium uses the system's libnss (, but bundles its own copy of libssl (extracted from NSS). Which means I can use the NSS patch from comment 8 and our Chromium 43+ builds will continue to be safe from Logjam even after we update to NSS 3.19.2 in Arch Linux. This is great! :)
I'm not certain this is the exact change that caused it, but it's ridiculous to force this ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY problem down end-users' throats when in many cases (e.g. routers, Cisco UCM, ...) they have little or no control over the server, and in some environments (internal corporate networks) the risk is relatively low.  Sure, warn them... but there has to be a workaround/ignore option available at least for a reasonable grace period.

Comment 33 by, Sep 11 2015

There was a more than reasonable grace period, Chrome was the last browser to fix this vulnerability. Internet Explorer was patched in May and Firefox in July. You should complain to the vendors who don't patch their software/hardware, not the browser developer who is trying to make the internet a little more secure.

Sign in to add a comment