Closed Bug 1227519 Opened 9 years ago Closed 6 years ago

Establish deprecation date for DHE cipher suites in WebRTC

Categories

(Core :: WebRTC, defect, P2)

Product:
Core
Component:
WebRTC
Version:
44 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla65
Tracking Flags:
Tracking Status
firefox65 --- fixed

People

(Reporter: tranogatha, Assigned: drno)

References

Details

(Keywords: site-compat)

Attachments

(1 file)

Bug 1227519: remove DHE ciphers from WebRTC DTLS handshake. r?mt
46 bytes, text/x-phabricator-request
Details | Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151124004047

Steps to reproduce:

Establish deprecation date for DHE ciphersuits.

Few implement DHE correctly, and ECDHE is better anyway, hence plan for getting rid of DHE ciphersuits.
Group: firefox-core-security
Component: Untriaged → Security: PSM
Flags: needinfo?(rlb)
Product: Firefox → Core
This is a good idea, whose time has perhaps not yet come.

- DHE is used in about 2% of TLS transactions [1]
- DHE usage is generally trending downward already [2]
- We've already taken the easy steps of:
  1. Not offering any non-ephemeral suites
  2. Preferring DHE suites below everything else but RC4

Net of that, marking NEW, but I'm not sure there's immediate action to take.

[1] http://mzl.la/1JBsZyA
[2] https://ipv.sx/telemetry/general-v2.html?channels=beta%20release&measure=SSL_KEY_EXCHANGE_ALGORITHM_FULL&target=2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(rlb)
Can you please explain why one would want to deprecate DHE, given that it currently is the only way to securely connect to a website without using dubious NSA curves for ECDHE?

I understand, DH/DHE _can be insecure_, but they also _can be secure_.
But can't everything be insecure? If webserver administrators simply don't configure their TLS system correctly, they IMO don't deserve to get a green padlock anyway.
Following up on this: Zakir Durumeric did some Zmap scans, first with the standard Firefox list of ciphersuites, and then without DHE.  He found that most things fell back to RSA:

DHE->Failure:    4348,  0.5%
DHE->ECDSA:     13681,  1.6%
DHE->RSA:      848283, 97.9%


So it looks like at this point in time, disabling DH would cause most transactions to move to RSA or fail, (vs. moving to ECDSA).
(In reply to Richard Barnes [:rbarnes] from comment #3)
> DHE->Failure:    4348,  0.5%
> DHE->ECDSA:     13681,  1.6%
> DHE->RSA:      848283, 97.9%
> 
> So it looks like at this point in time, disabling DH would cause most
> transactions to move to RSA or fail, (vs. moving to ECDSA).

It would be more useful to include the DHE and RSA key sizes. DHE-1024 -> RSA-2048 is an improvement given the current thinking regarding DHE-1024. When DHE is implemented well, DHE is better than RSA, but the problem is that DHE is too often not implemented well.
Chrome already disabled DHE in latest stable. It is time to do the same.
Whiteboard: [psm-deprecation]
Chrome is now fully removing DHE cipher suits, with no fallback handshake to enable them.

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/sVq6r0i-CZM

What is Mozilla's take on this?
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #4)
> It would be more useful to include the DHE and RSA key sizes. DHE-1024 ->
> RSA-2048 is an improvement given the current thinking regarding DHE-1024.
> When DHE is implemented well, DHE is better than RSA, but the problem is
> that DHE is too often not implemented well.

Here is your answer: https://www.chromestatus.com/feature/5128908798164992

"95% of DHE connections seen by Chrome use 1024-bit DHE". Firefox needs to catch up to Chrome in terms of security and deprecation of vulnerable features.
See Also: → 1279479
(In reply to Richard Barnes [:rbarnes] from comment #1)
> This is a good idea, whose time has perhaps not yet come.
> 
> - DHE is used in about 2% of TLS transactions [1]
Following up on this, https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/sVq6r0i-CZM claims that "Current metrics report 0.01% of TLS connections made by Chrome stable users over the past two weeks use DHE.".

That quote is from a month ago. This number is two orders of magnitude lower compared to 2% in December 2015.
Google has removed DHE for several versions of Chrome now. What is the progress on Mozilla's side?
This is blocked on Cisco Spark. See bug 1288246.
Chrome has now not had support for DHE for over half a year, and there were no issues observed on the internet as a result of it. It is safe and advisable for Firefox to remove DHE support as well.

Removing DHE support would have additional benefits of also fixing vulnerabilities such as this:
https://dh-small-subgroup.badssl.com/
https://dh-composite.badssl.com/

It would be excellent to have this removal land in Firefox 52 ESR so that we are not stuck with DHE for another full year.
Nothing has changed about Cisco Spark since comment #11.
Cisco spark works without DHE for months now.
Really? Nils, could you verify?
Flags: needinfo?(drno)
Cisco Spark still uses DHE to establish the DTLS connections for WebRTC calls. We are not talking here just about loading the web page.
I just verified it with Nightly and the DHE disable plugin. DTLS connections fails to establish.

One option might be to disable DHE for HTTPS but leave it enabled for WebRTC. Ekr, Marting what are your thoughts on this?
Flags: needinfo?(martin.thomson)
Flags: needinfo?(ekr)
Flags: needinfo?(drno)
Still at 1% in *Nightly*.  Can't see this happening any time soon.
Flags: needinfo?(martin.thomson)
(In reply to Martin Thomson [:mt:] from comment #17)
> Still at 1% in *Nightly*.  Can't see this happening any time soon.

Note that most those servers will select different cipher suites if we don't offer DHE.
Yes, but we don't know how many are OK without DHE.  Unless we do something to measure this, we're stuck where we are.
(In reply to Martin Thomson [:mt:] from comment #19)
> Yes, but we don't know how many are OK without DHE.  Unless we do something
> to measure this, we're stuck where we are.

I'll retry to hide DHE cipher suites behind fallback without affecting WebRTC.
The original spirit of this bugreport was to establish a date by which Firefox will stop support for DHE. Do we have a date?

Chrome has removed all support for DHE, with no fallback at all, almost a year ago. This means that there are now exactly zero public websites that require DHE. Firefox needs to step up its security efforts in deprecating old technologies by catching up to what Chrome is doing.

Unfortunately, DHE is still supported in Firefox 52 ESR, which means ESR users will be plagued by weak security for a whole another year. Yes, DHE is insecure because of the impossible effort in getting rid of support for common DH primes, DH param reuse, 1024bit DH strength, small DH subgroups, and use of DH composite groups over weak primes. DHE has been a nightmare in proper implementation, almost universally done wrong.

Cisco needs to move away from DHE, especially if they wish to support Chrome. In the meantime, keeping support for DHE for the sake of one vendors implementation (with lots of alternatives available) just makes everyone less secure.

DHE needed to die a long time ago. Let's make that happen on Firefox's side too.
To clarify one more time: the Cisco Spark issue is purely about DTLS when using WebRTC (which means only when you make calls). As everyone can see here https://www.ssllabs.com/ssltest/analyze.html?d=web.ciscospark.com the Cisco Spark web page does actually not use DHE cipher suites. So the Cisco Spark web page does NOT depend on DHE cipher suites, but their WebRTC calling solution does.
In other words: Cisco Spark does not prevent us from removing the DHE cipher suites from Firefox HTTP TLS client hello.

Now as everyone keeps referring to Google Chrome having remove DHE ciphers already: I just made a WebRTC call with Chrome 56 and it offered the following cipher suites:
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

As you can see even though Chrome apparently does not offer DHE ciphers suites in its TLS HTTP client, it still does offer DHE in its DTLS client hello message from it's WebRTC client.

So if we remove the DHE cipher suites we just need to be more careful then last time to not remove the DHE cipher suites from the WebRTC DTLS client as well.
I hid DHE cipher suites from the first handshake (bug 1279479). Once it reaches the release and our telemetry indicates DHE usage is indeed low, I will disable DHE cipher suites completely in TLS HTTP requests.
Priority: -- → P3
According to telemetry.mozilla.org (going away soon?) 0.8% of SSL_CIPHER_SUITE_FULL are DHE on Release 57. That's well after bug 1279479 landed. Do we have any scans that might give us a clue what kinds of sites those are?
Flags: needinfo?(VYV03354)
I don't know. Matt?
Flags: needinfo?(VYV03354) → needinfo?(mwobensmith)
Note that TLS 1.3 is still disabled in release such that but 1279479 shouldn't affect release. Looking at telemetry from beta and nightly DHE cipher suites are completely gone, which suggests that the sites we see in release telemetry negotiate other cipher suites.
Summary: Establish deprecation date for DHE ciphersuits → Establish deprecation date for DHE cipher suites
(In reply to Masatoshi Kimura [:emk] from comment #25)
> I don't know. Matt?

This looks like a job for TLS Canary. :)

Can you specify which are the cipher suites in question? Just the first two?

security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256
security.ssl3.ecdhe_ecdsa_aes_128_sha
security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384
security.ssl3.ecdhe_ecdsa_aes_256_sha
security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
security.ssl3.ecdhe_rsa_aes_128_sha
security.ssl3.ecdhe_rsa_aes_256_gcm_sha384
security.ssl3.ecdhe_rsa_aes_256_sha
security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256
Flags: needinfo?(mwobensmith)
Flags: needinfo?(VYV03354)
Yes.  Matt, the security.ssl3.dhe_ suites are the ones we are interested in.
Flags: needinfo?(ekr)
Oops, clear the wrong n-i.
Flags: needinfo?(VYV03354)
(In reply to Franziskus Kiefer [:fkiefer or :franziskus] from comment #26)
> Note that TLS 1.3 is still disabled in release such that but 1279479
> shouldn't affect release. Looking at telemetry from beta and nightly DHE
> cipher suites are completely gone, which suggests that the sites we see in
> release telemetry negotiate other cipher suites.

Ah, I forgot that bug 1279479 depends on TLS 1.3. Thank you for pointing it out.
(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #27)
> (In reply to Masatoshi Kimura [:emk] from comment #25)
> > I don't know. Matt?
> 
> This looks like a job for TLS Canary. :)
> 
> Can you specify which are the cipher suites in question? Just the first two?
> 
> security.ssl3.dhe_rsa_aes_128_sha
> security.ssl3.dhe_rsa_aes_256_sha
> security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256
> security.ssl3.ecdhe_ecdsa_aes_128_sha
> security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384
> security.ssl3.ecdhe_ecdsa_aes_256_sha
> security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256
> security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
> security.ssl3.ecdhe_rsa_aes_128_sha
> security.ssl3.ecdhe_rsa_aes_256_gcm_sha384
> security.ssl3.ecdhe_rsa_aes_256_sha
> security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256

Just the first two as Martin said.

It would be great if we can compare with and without TLS 1.3 enabled (security.tls.version.max=3 and 4).
Coming right up, should have results in a day.
I am having issues pushing the reports to the live web site, but here are the results below. 

They are the same with and without TLS 1.3 enabled. 

Rank, host

11325	directv.com		
73241	autoanything.com		
127387	ad.adworx.at		
162749	komando.com		
198730	backupmanager.info		
353078	hknet.com		
534684	assets.miyuki.mobi		
552457	p4.net		
584165	directtv.com		
598658	supanet.com		
668900	ilmioabbonamento.espresso.repubblica.it		
729176	plune.com.br		
786213	myub.buffalo.edu		
881656	biotaxa.org		
910272	static.komando.com		
942328	mcallen.net		
987752	graphics.komando.com
Looks like it is safe to completely disable DHE. No need to hide it behind a fallback handshake.

We would be interested in making sure this change is present in Firefox 60 ESR, so that DHE does not stick around for yet another year.
We probably can't break directv, so I disagree - we shouldn't directly disable these for now.
(In reply to David Keeler [:keeler] (use needinfo) from comment #36)
> We probably can't break directv, so I disagree - we shouldn't directly
> disable these for now.

Please note that there is a difference between directv.com and www.directv.com

https://www.ssllabs.com/ssltest/analyze.html?d=directv.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.directv.com

www.directv.com is the correct webpage (that they advertise everywhere).
Unless there are any comments against this proposal, I suggest we implement the disabling/removal of DHE in Firefox as soon as possible.
I still have compatibility concerns about making this change. At the very least, we should implement a fallback mechanism like we did for RC4.
Any progress on this issue? https://dh1024.badssl.com/ still shows a perfectly green extra secure lock on it despite using very vulnerable cryptography in latest Firefox beta.
At my request, DIRECTV have fixed their website.

https://www.ssllabs.com/ssltest/analyze.html?d=directv.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.directv.com

This should fix your last concerns with removing DHE support from Firefox.

Matt can you run another TLS canary please? Thank you.
Flags: needinfo?(mwobensmith)
Is there a firm date set?

A surprisingly large number of secure websites can be accessed today using just these two cipher suites:

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   Forward Secrecy 	256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   Forward Secrecy 	256

What is the argument against a compact, sufficient set of secure suites, rather than keep nursing along suboptimal suites for long periods because somebody, somewhere is still using them?
Restrict Comments: true
Hi, comments on a bug are not a place for debate or advocacy on "why hasn't the bug been addressed?" See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.

We ask this because we want the comments to be focused on the solution, and because each comment on a bug generates an email to everyone in the thread. We want those emails to be useful to those receiving them.

For the moment we've turned off commenting on the bug for non-contributors. (And this comment's been added using an account that can comment without generating bugmails.)
This is effectively fixed by bug 1479501 except for WebRTC because we offer DHE cipher suites only if we don't offer TLS version 1.3.

But we still offer DHE cipher suites for WebRTC due to bug 1288246.
Component: Security: PSM → WebRTC
Resetting priority flags so this can be re-triaged.
Priority: P3 → --
Whiteboard: [psm-deprecation]
Priority: -- → P5
Cisco Spark no longer depends on DHE. We should add some Telemetry to check how often DHE is still used.
Assignee: nobody → drno
Priority: P5 → P2
Depends on: 1484024
Telemetry probe is https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-27&keys=__none__!__none__!__none__&max_channel_version=nightly%252F63&measure=WEBRTC_DTLS_CIPHER&min_channel_version=nightly%252F60&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-08-25&table=1&trim=0&use_submission_date=0

And reports no usage of DHE in three days of Nightly. We will wait for the data from 63 Beta cycle.
Summary: Establish deprecation date for DHE cipher suites → Establish deprecation date for DHE cipher suites in WebRTC
Keywords: site-compat
See Also: → 1215456
Apologies, I no longer maintain the TLS Canary project and have moved to a different team. Anyone who wishes to run the TLS Canary can do so by getting the project via pip or via GitHub [1].

[1] https://github.com/mozilla/tls-canary
Flags: needinfo?(mwobensmith)
So in one month 63 Beta cycle we have 3 counts for DHE out of 22 million samples. At the same time in the Nightly 64 cycle we have had 21 count of of 2 million samples. Looks like it is pretty safe to remove DHE ciphers from WebRTC DTLS.
Current intention is to land the removal once Firefox 65 opens at the end of October (assuming we don't hear any major concerns in the remaining time).
(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #50)
> Apologies, I no longer maintain the TLS Canary project and have moved to a
> different team. Anyone who wishes to run the TLS Canary can do so by getting
> the project via pip or via GitHub [1].
> 
> [1] https://github.com/mozilla/tls-canary

That would be my team! FYI to anyone in this thread, that the PI Security Testing team has taken over the maintenance and running of TLS canary. Please file  PI request for asks, or need-info Christiane Ruetten for future requests like this. 

(In reply to Nils Ohlmeier [:drno] from comment #53)
> Current intention is to land the removal once Firefox 65 opens at the end of
> October (assuming we don't hear any major concerns in the remaining time).

So from comment 49 it sounds like we already have telemetry data to support removing DHE. But I suppose it would be prudent to do a comparison with TLS canary after DHE removal lands?
Hi folks, let's differentiate between HTTPS and WebRTC. TLS Canary only picks up HTTPS, but this bug is about WebRTC.
See Also: → 1496639
(In reply to Paul Theriault [:pauljt] from comment #54)
> (In reply to Nils Ohlmeier [:drno] from comment #53)
> > Current intention is to land the removal once Firefox 65 opens at the end of
> > October (assuming we don't hear any major concerns in the remaining time).
> 
> So from comment 49 it sounds like we already have telemetry data to support
> removing DHE. But I suppose it would be prudent to do a comparison with TLS
> canary after DHE removal lands?

Well this is (now) about WebRTC DHE. And I don't think that TLS canary can do WebRTC, or?
Pushed by nohlmeier@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ae266baf08fe
remove DHE ciphers from WebRTC DTLS handshake. r=mt
https://hg.mozilla.org/mozilla-central/rev/ae266baf08fe
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Depends on: 1528164
No longer depends on: 1528164
Regressions: 1528164
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: