1325257 - Deprecate and remove: TLS 1.2 ECDSA with SHA-1 and SHA-512 signature algorithms

Status: RESOLVED DUPLICATE of bug 1600437

(Core :: Security: PSM, task, P3)

Description

[Masatoshi Kimura [:emk]]

+++ This bug was initially created as a clone of Bug #1316300 +++

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20100101

Steps to reproduce:

Catch up to chrome deprecating old/unused features related to security

https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/A-LcSmj5TBE

Comment 1

[Jonathan Kingston [:jkt] he/him]

Should this bug also deprecate https://bugzilla.mozilla.org/show_bug.cgi?id=1316300 for TLS 1.1?

mib_vcdhrr asked on irc.

Is there any intent to do this change this year?

Comment 2

[Franziskus Kiefer [:franziskus]]

I don't see a reason to deprecate cipher suites with SHA512 (Chrome is doing it is not a good reason). For ECDSA with SHA1 we should do some canary run to see what we break. Unfortunately this information doesn't seem exposed via prefs so it requires code changes first.
I don't think this is very high on any priority list.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Thanks

Comment 4

[ht16cq+b33nskirkppis]

If I understand this correctly, this is about deprecating TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a).

These suites are no longer exposed in TLSv1.3 handshake, but are exposed in TLSv1.2 and lower.

A TLS Canary run should be made, with those suits enabled and disabled. Neither has been supported by Chrome in quite some time, so I do not expect any relevant breakage.

Probably best to remove them IMO.

Comment 5

[ht16cq+b33nskirkppis]

The ones that need to be tested in TLS Canary are:

security.ssl3.ecdhe_ecdsa_aes_128_sha
security.ssl3.ecdhe_ecdsa_aes_256_sha

If this change were to be made, it would be preferable to get it done in time for Firefox 60 ESR so that those cipher suits do not hang around for another year.

Comment 6

[Martin Thomson [:mt:]]

These ciphersuites happen to be the best ciphersuites we can negotiate with TLS 1.0.  I don't see any reason to remove them unless we also intend to remove TLS 1.0.

Comment 7

[ht16cq+b33nskirkppis]

(In reply to Martin Thomson [:mt:] from comment #6)
> These ciphersuites happen to be the best ciphersuites we can negotiate with
> TLS 1.0.  I don't see any reason to remove them unless we also intend to
> remove TLS 1.0.

Please note that this is about the ECDSA cipher suites, not RSA cipher suites.

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

have not been supported by Chrome in over a year, and in my personal testing are not used on the internet anymore. I only wanted a TLS Canary run to get some in-house mozilla numbers for it too.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

will remain. TLSv1.0 support thus remains unaffected.

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

Using Fx60, and turning off just the two suites mentioned in comment 5, the canary did not find any breakage.

Comment 9

[ht16cq+b33nskirkppis]

Unless there are any comments against this proposal, I suggest we implement the disabling/removal of TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SH and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA in Firefox as soon as possible.

Comment 10

[ht16cq+b33nskirkppis]

It is saddening how little attention this issue is getting. It demonstrates that Mozilla has no specific plans to deprecate old insecure technologies nor a way of even determining a specific deprecation date.

Despite both factual evidence through TLS-canary, and anecdotal evidence of many users reporting no breakage, this issue still remains after many years.

Chrome, on the other hand, quickly deprecates old insecure technologies, and even establishes specific dates when the technologies will be gone. This is one of the reasons why Chrome is a more secure browser than Firefox.

If Firefox hopes to ever catch up to Chrome in terms of security, it needs to start copying the security practices that Chrome has, instead of being stuck in the past.

Comment 11

[Ciprian.Enache]

This is a workaround. I have been using Firefox for more than 1 year with the following settings:

• security.ssl3.ecdhe_ecdsa_aes_128_sha=false (uses CBC and SHA-1)
• security.ssl3.ecdhe_ecdsa_aes_256_sha=false (uses CBC and SHA-1)
• security.ssl3.ecdhe_rsa_aes_128_sha=false (uses CBC and SHA-1)
• security.ssl3.ecdhe_rsa_aes_256_sha=false (uses CBC and SHA-1)
• security.ssl3.rsa_aes_128_gcm_sha256=false (no perfect forward secrecy - PFS)
• security.ssl3.rsa_aes_128_sha=false (uses CBC, SHA-1, no PFS)
• security.ssl3.rsa_aes_256_gcm_sha384=false (no PFS)
• security.ssl3.rsa_aes_256_sha=false (uses CBC, SHA-1, no PFS)

No sites (that I know of) are broken by this. You can verify your current settings at either https://browserleaks.com/ssl or https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.