Intent to Remove: DHE-based ciphers

[David Benjamin]

Primary eng (and PM) emails

davi...@chromium.org

awha...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/AAdv838-koo/bJv17voIBAAJ

Summary

We plan to remove DHE-based cipher suites.

Motivation

Last year, we raised the minimum TLS Diffie-Hellman group size from 512-bit to 1024-bit. As mentioned then, 1024-bit is insufficient for the long-term. However, metrics reported that around 95% of DHE connections seen by Chrome use 1024-bit DHE. This, compounded with how DHE is negotiated in TLS, makes it difficult to move past 1024-bit.

Although there is a draft specification which fixes the negotiation problems, it is still a draft and requires both client and server changes. Meanwhile, ECDHE is already widely implemented and deployed. We do not feel it is practical to continue supporting DHE.

For a more detailed explanation, see the Intent to Deprecate thread.

Compatibility Risk

Servers which support only DHE ciphers will stop working in Chromium-based browsers. Note this is fewer than servers which merely prefer DHE. Typically servers have other ciphers available. See usage information below.

The latest versions of Safari on both OS X and iOS removed DHE support, so most affected sites are already inaccessible in Safari. (Unless they also accept ciphers like RC4 which we no longer offer but Safari still does.) Edge and Firefox also advertise fewer DHE ciphers than we do (only AES-GCM and only AES-CBC DHE ciphers, respectively), which also limits the pool.

Usage information from UseCounter

Current metrics report 0.01% of TLS connections made by Chrome stable users over the past two weeks use DHE. DHE has been placed on a fallback, so this is roughly the connections which required DHE, though there may be some false positive noise due to unreliability of fallbacks.

OWP launch tracking bug

https://crbug.com/619194

Entry on the feature dashboard

https://www.chromestatus.com/feature/5128908798164992

Additional considerations
As with the version fallback removal, we include a field trial to roll this back should unforeseen issues occur. There will also be a time-limited administrative policy knob, in case the enterprise population, where we are normally blind, is drastically different from our UMA population.

We will not be attempting a user-visible link on the error page. We experimented with that in the version fallback removal, but this caused too much confusion between target audiences of the UI.

We will, however, surface a new dedicated net error code, ERR_SSL_OBSOLETE_CIPHER, as this has worked well for the version fallback. With the RC4 removal, errors could end up under ERR_CONNECTION_CLOSED, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, ERR_CONNECTION_RESET, and possibly others, depending on the server’s behavior. TLS has the client offer parameters which the server selects, so, a priori, clients do not know why a connection didn’t work. But we can modify our measurement fallback and get something reasonably accurate.

Today, Chrome connects in two tries:

1. Send a ClientHello without DHE.

2. If that fails, add DHE back in and retry.

This was done for measurement purposes, to distinguish between sites which prefer DHE vs. requiring it. We will change it to:

1. Send a ClientHello without DHE.

2. If that fails, add DHE back in and retry. If this retry uses a DHE-based cipher, reject the connection with ERR_SSL_OBSOLETE_CIPHER.

Then, in a few releases' time, we will remove step 2 and connect in one step. Any remaining DHE-only servers will revert to a more generic error as with RC4. If this works well, we’ll reuse this pattern for future cipher suite removals.

Note that, as with the histograms and the version fallback's error code, there will be some false positive noise on transient network errors to DHE-preferring servers.

David

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Does Chrome currently shows an insecure connection indicator for the sites that use this?

If not, can it? This will be some kind of a deprecation warning period.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOMQ%2Bw8WsKYQ0UG6hT%3DXFtmrgcgsP8OaW_AWFO_10qK0kd25pg%40mail.gmail.com.

[David Benjamin]

See the Intent to Deprecate thread. We show a warning in DevTools like other deprecations. (Actually the deprecation text said it'd be gone in M52. I ended up getting tied up in other things last cycle and didn't have time to follow-up here. :-/ )

From past deprecations, security UI folks have asked that we not involve the lock icon and I agree. Using the lock icon has been rather a mess from experience with the SHA-1 deprecation. Fortunately, the numbers are in line with past Blink and TLS deprecations, rather than SHA-1, so we don't need anything close to SHA-1's protracted and painful process.

(We didn't touch the lock icon for RC4 either.)

[Rick Byers]

I'm a little nervous about the 0.01% figure - that's still a LOT of connections to be blocking them outright.

However, the fact that Safari already dropped support for this is huge (they tend to be more conservative than we are about breaking changes).  Perhaps that's a sign that most of these DHE connections are for resources that don't impact the user experience much.  Do you have a list of some known affected sites?  It would be informative to check whether most of a random sample of sites to broken in Chrome are also broken in Safari, and how serious the breakage is.

Your risk mitigations (admin opt-out and finch trial) also decrease the risk a lot.  There's not also a temporary chrome://flags entry, is there?  Is your plan to disable the experiment and re-evaluate if there's non-trivial user feedback of major breakage?  If so, LGTM2 to remove (little harm in trying if we can respond quickly).

[David Benjamin]

On Mon, Jun 13, 2016 at 11:12 AM Rick Byers <rby...@chromium.org> wrote:

I'm a little nervous about the 0.01% figure - that's still a LOT of connections to be blocking them outright.

[Strictly speaking, the 0.01% includes some false positive noise, but I don't have a way to quantify it, so we should assume conservatively that the number's accurate.]

 

However, the fact that Safari already dropped support for this is huge (they tend to be more conservative than we are about breaking changes).  Perhaps that's a sign that most of these DHE connections are for resources that don't impact the user experience much.  Do you have a list of some known affected sites?  It would be informative to check whether most of a random sample of sites to broken in Chrome are also broken in Safari, and how serious the breakage is.

Safari dropped it around the time when Logjam was coming around. Rather than add a limit, they took DHE out altogether. So that might explain their uncharacteristically less conservative move. :-) The alternative, our ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY woes, was even more painful.

From probing a list of top million hosts (nothing fancy, I just grabbed Alexa top million), I found 476 broken hosts. 107 serve redirects to an http URL anyway. Of the remaining 369, 89 are broken in Safari and 199 will be broken in Edge once they drop RC4. The discrepancy is because Safari still does RC4 and, while Edge still has DHE, they only do DHE + AES-GCM while we do a lot more DHE ciphers.

If Safari ever drops RC4, all but 6 of the 369 will be broken in Safari too.

(Note: assume all numbers are only accurate up to maybe 5 or 10 hosts. Spurious network errors can happen when probing.)

That does still leave a decent number of hosts that we'll break. Though the fix for each of these is going to be very straightforward. Change one line on server config. I'm expecting to have to do some work reaching out to sites before and after the change, but we weathered a larger one of these with RC4 and have the escape hatch if it doesn't work.

 

Your risk mitigations (admin opt-out and finch trial) also decrease the risk a lot.  There's not also a temporary chrome://flags entry, is there?  Is your plan to disable the experiment and re-evaluate if there's non-trivial user feedback of major breakage?  If so, LGTM2 to remove (little harm in trying if we can respond quickly).

I wasn't planning for a chrome://flags entry, but it's easy enough. I figure we don't really intend for that to be UI we send users to and the dedicated error code means we don't need it for diagnosing sites.

But yeah, that's the idea. I'll be watching UMA (new error code makes this easier) and user feedback to see how bad it is. If we have to, we'll be able to back out without shipping new code.

David

[David Benjamin]

On Mon, Jun 13, 2016 at 5:50 PM David Benjamin <davi...@chromium.org> wrote:

On Mon, Jun 13, 2016 at 11:12 AM Rick Byers <rby...@chromium.org> wrote:

I'm a little nervous about the 0.01% figure - that's still a LOT of connections to be blocking them outright.

[Strictly speaking, the 0.01% includes some false positive noise, but I don't have a way to quantify it, so we should assume conservatively that the number's accurate.]

 

However, the fact that Safari already dropped support for this is huge (they tend to be more conservative than we are about breaking changes).  Perhaps that's a sign that most of these DHE connections are for resources that don't impact the user experience much.  Do you have a list of some known affected sites?  It would be informative to check whether most of a random sample of sites to broken in Chrome are also broken in Safari, and how serious the breakage is.

Safari dropped it around the time when Logjam was coming around. Rather than add a limit, they took DHE out altogether. So that might explain their uncharacteristically less conservative move. :-) The alternative, our ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY woes, was even more painful.

From probing a list of top million hosts (nothing fancy, I just grabbed Alexa top million), I found 476 broken hosts. 107 serve redirects to an http URL anyway. Of the remaining 369, 89 are broken in Safari and 199 will be broken in Edge once they drop RC4. The discrepancy is because Safari still does RC4 and, while Edge still has DHE, they only do DHE + AES-GCM while we do a lot more DHE ciphers.

Er, I should have spelled that out more clearly. For some reason, a few hosts configure:

DHE_RSA + AES_CBC

RSA + RC4

(Broken in Safari and Edge iff they lose RC4)

or

DHE_RSA + AES_GCM

DHE_RSA + AES_CBC

RSA + RC4

(Broken in Safari iff they lose RC4, fine in Edge even after they lose RC4 unless they also lose their DHE ciphers.)

I really don't know where this configuration comes from as it makes no sense. My best guess is that Safari's removal of DHE (a while ago) means they've already cleared out all DHE-requiring sites that would have broken in Safari, so what's left is the weirdos who somehow managed to have this configuration and wouldn't have been caught.

[PhistucK]

On Tue, Jun 14, 2016 at 12:50 AM, David Benjamin <davi...@chromium.org> wrote:

If Safari ever drops RC4, all but 6 of the 369 will be broken in Safari too.

​

What about those remaining 6? Why would Chrome fail and Safari succeed?

☆PhistucK

[Rick Byers]

Thanks for the detailed analysis!  Also I assume most (or all) of these broken sites support HTTP (don't use HSTS or anything) so users can generally get around the issue by just falling back to HTTP, right?  I was forgetting that when I suggested adding a flag.

Anyway sounds like a good plan.  Anyone else want to chime in?

  Rick

[David Benjamin]

On Tue, Jun 14, 2016 at 4:41 AM Rick Byers <rby...@chromium.org> wrote:

Thanks for the detailed analysis!  Also I assume most (or all) of these broken sites support HTTP (don't use HSTS or anything) so users can generally get around the issue by just falling back to HTTP, right?  I was forgetting that when I suggested adding a flag.

Anyway sounds like a good plan.  Anyone else want to chime in?

  Rick

Not sure. That's a good thing to check. I'll look for redirects to https on the http side which should give a rough estimate. If HTTP is accessible and doesn't redirect, my guess is the HTTPS version isn't used much. (The Alexa list I was using doesn't say whether the site is typically accessed over HTTP or HTTPS.)

Although neither this nor the HTTPS -> HTTP redirect heuristic are perfect. The site may only use HTTPS for, say, some employee login portal.

 

On Tue, Jun 14, 2016 at 1:51 AM, PhistucK <phis...@gmail.com> wrote:

On Tue, Jun 14, 2016 at 12:50 AM, David Benjamin <davi...@chromium.org> wrote:

If Safari ever drops RC4, all but 6 of the 369 will be broken in Safari too.

​

What about those remaining 6? Why would Chrome fail and Safari succeed?

They use the TLS 1.2 SHA-256 CBC mode ciphers which Safari offers but we (and Firefox) do not. Not sure where that configuration came from either, but it's a large web. People do the strangest things.

(Absent a particularly good compatibility reason, I don't want to add new CBC ciphers. CBC ciphers in TLS are known broken and we shouldn't encourage further use.)

David

[Rick Byers]

On Tue, Jun 14, 2016 at 12:09 PM, David Benjamin <davi...@chromium.org> wrote:

On Tue, Jun 14, 2016 at 4:41 AM Rick Byers <rby...@chromium.org> wrote:

Thanks for the detailed analysis!  Also I assume most (or all) of these broken sites support HTTP (don't use HSTS or anything) so users can generally get around the issue by just falling back to HTTP, right?  I was forgetting that when I suggested adding a flag.

Anyway sounds like a good plan.  Anyone else want to chime in?

Ping foolip, dglazkov, tkent, jochen - need approval or feedback from another API owner here.

Sorry for the delay, BlinkOn was last week so we've all be travelling (or in jochen's case organizing like mad <grin>).

[Dimitri Glazkov]

LGTM.

:DG<

[chrc...@msn.com]

I know this is old and the changes have already been commited, but I have a question which would seem obvious to me.

Why didnt you just enforce 2048 bit on DHE, wouldnt that still fall back to a ECDHE when it fails?  The difference then would be more sites would work at least.

I came here because as I was wanting to move my ECDHE ciphers below DHE in my cipher preference as I am not happy using NIST curves with NSA backdoors in, but then found that chome and firefox are now effectively forcing the use of curves unless I use a weaker cipher.

I would be fine using ECDHE with either brainpool or the excellent 25519 but yet somehow you guys picked the worst curves to use and left the best one's out, is there any plan to add support for these curves?

[David Benjamin]

On Wed, Sep 28, 2016 at 9:52 PM <chrc...@msn.com> wrote:

I know this is old and the changes have already been commited, but I have a question which would seem obvious to me.

Why didnt you just enforce 2048 bit on DHE, wouldnt that still fall back to a ECDHE when it fails?  The difference then would be more sites would work at least.

It won't fall back to ECDHE. The protocol doesn't let the client guide the server on group choice, so, by the time we find a bad group, it's too late and the parameters have already been selected. (Unlike ECDHE, DHE did not use named well-known groups and has the server select emit parameters by fiat.)

 

I came here because as I was wanting to move my ECDHE ciphers below DHE in my cipher preference as I am not happy using NIST curves with NSA backdoors in, but then found that chome and firefox are now effectively forcing the use of curves unless I use a weaker cipher.

I would be fine using ECDHE with either brainpool or the excellent 25519 but yet somehow you guys picked the worst curves to use and left the best one's out, is there any plan to add support for these curves?

We already support X25519. We have since Chrome 50, released around April, several releases before this change.

https://www.chromestatus.com/feature/5682529109540864 

(There are no plans to support brainpool curves.)

David