1600437 - Consider removing ECDSA_SHA1 signature algorithm

Status: RESOLVED FIXED

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

Description

[Darkspirit]

It's forbidden in TLS 1.3 and Chrome removed it years ago for TLS 1.2, too.
https://tools.ietf.org/html/rfc8446#page-42
https://tools.ietf.org/html/rfc8446#page-44
https://bugs.chromium.org/p/chromium/issues/detail?id=655318
https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=75&platform=Win%2010&key=154
https://www.ssllabs.com/ssltest/viewMyClient.html

https://searchfox.org/mozilla-central/rev/d69bff9bdb2dcf1788eec6232b21eb3eec342799/security/manager/ssl/nsNSSIOLayer.cpp#2075-2084
https://searchfox.org/mozilla-central/rev/d69bff9bdb2dcf1788eec6232b21eb3eec342799/security/manager/ssl/nsNSSCallbacks.cpp#635
https://searchfox.org/mozilla-central/rev/d69bff9bdb2dcf1788eec6232b21eb3eec342799/security/nss/lib/ssl/ssl3con.c#177-200

Comment 1

[Darkspirit]

(bug 1600449 is about showing a warning message for RSA_PKCS1_SHA1 as it can't be removed yet.)

Comment 2

[J.C. Jones [:jcj] (he/they)]

Marking for 3.50 in Q1

Comment 3

[Darkspirit]

I guess this also means that ECDHE-ECDSA-AES256-SHA and ECDHE-ECDSA-AES128-SHA couldn't be used with TLS 1.0 and 1.1 anymore.
Chrome completely removed them in 2016 and I removed them from Servo, too, as they are unused:
Ciphersuites 4 and 6 on SSL_CIPHER_SUITE_FULL (even less with Nightly).

Comment 4

[Darkspirit]

Attachment: Bug 1600437 - Disable CBC-mode ECDSA ciphers and stop advertising ECDSA+SHA1 signature algorithm. r=nkulatova

Comment 5

[Darkspirit]

This patch should remove SHA1/ECDSA from TLS 1.2.
https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html.

Comment 6

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

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:jan, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 7

[Darkspirit]

rebased.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d0ac295c1b62
Disable CBC-mode ECDSA ciphers and stop advertising ECDSA+SHA1 signature algorithm. r=nkulatova

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d0ac295c1b62

Comment 10

[morgan (Tor Project)]

Could this possibly be backported to esr102?

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler]]

We generally don't backport patches with potential compatibility risks to ESR. If you're wanting to take this for TBB, a previous revision of the patch probably applies cleanly, if the current one doesn't.

Comment 13

[Darkspirit]

(I'm not a cryptographer.)

Overview:

• certs

  • February 23, 2017: https://blog.mozilla.org/security/2017/02/23/the-end-of-sha-1-on-the-public-web/

• ciphersuites

  • Chromium completely removed ECDHE-ECDSA-AES[256,128]-SHA in March 2017:
    https://bugs.chromium.org/p/chromium/issues/detail?id=666191 = https://chromium.googlesource.com/chromium/src/+/0b6de43d2f326542de3756c46bb3c98b63880f62%5E%21/
  • numbers of 4 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA) and 6 (TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA) are so small (345 + 6.23k) that no bar is visible in the telemetry diagram.

• signature schemes:

  • 2015: https://www.mitls.org/pages/attacks/SLOTH

    We encourage TLS 1.2 implementations to disable MD5 signatures immediately and SHA1 signatures as soon as practical
    TLS 1.2 Client Auth RSA-SHA1 or ECDSA-SHA1 Impersonation Chosen Prefix
    TLS 1.2 Server Auth RSA-MD5 Impersonation Generic
    TLS 1.3 Server Auth RSA-SHA1 or ECDSA-SHA1 Impersonation Chosen Prefix

    • MD5 = bug 1158489 in 2015
    • https://en.wikipedia.org/wiki/SHA-1

      As of 2020, chosen-prefix attacks against SHA-1 are practical.

  • In 2016, Chromium removed support for ECDSA_SHA1 signature algorithm for verification, but apparently still supports it for signing (client certs?).
    https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/extensions.cc;l=430-471;drc=9d64d8d2373db494d3460102b970f4aaf92ee274
    https://bugs.chromium.org/p/chromium/issues/detail?id=655318#c1

  • February 2020: Chromium restricts rsa_pkcs1_sha1 to being a fallback:
    https://bugs.chromium.org/p/chromium/issues/detail?id=658905#c10
    https://source.chromium.org/chromium/chromium/src/+/main:net/socket/ssl_client_socket_impl.cc;l=861-862;drc=52fa5a7f263b37149bcfbac06da00fec5abcc416
    https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI

    To gather more accurate usage metrics, we'll be moving SHA-1 signature algorithms in TLS 1.2, and 3DES cipher suites, to a fallback connection beginning with Chrome 82.
    This is not expected to break any sites, including those which rely on the obsolete algorithms, and we do not yet have a concrete removal timeline, so this is not an Intent to Deprecate.

    The server signature is sensitive to these SHA-1 attacks. Note this is not the signature in the certificate, computed by CAs. It is the signature in the TLS handshake itself, computed by the TLS server software. The TLS working group has adopted a document to deprecate this use of SHA-1.

    In 2016, we removed support for ECDSA SHA-1 server signatures, but RSA SHA-1 remains. Around 1% of connections from Chrome are to servers which select RSA SHA-1, but we expect the true impact of removal is much lower.

  • 30 Dec 2021: https://www.feistyduck.com/bulletproof-tls-newsletter/issue_84_rfc_9155_deprecates_md5_and_sha-1_signatures_in_tls_handshake_messages
    https://datatracker.ietf.org/doc/html/rfc9155 deprecated ecdsa_sha1 and rsa_pkcs1_sha1.

    NIST formally deprecated use of SHA-1 in 2011
    [NISTSP800-131A-R2] and disallowed its use for digital signatures at
    the end of 2013,

    This document updates
    [RFC5246 ==TLS 1.2] in such a way that MD5 and SHA-1 MUST NOT be used for
    digital signatures. However, this document does not deprecate SHA-1
    with HMAC, as used in record protection. Note that the CA/Browser
    Forum (CABF) has also deprecated use of SHA-1 for use in certificate
    signatures [CABF].

  • I assume the next step for Nightly and Beta would be restricting ssl_sig_rsa_pkcs1_sha1 to security.tls.version.enable-deprecated=true and/or bug 1600449?

Comment 14

[Hamish Willee]

What MDN documentation do you think might be needed for this? The only mention I can find of ECDSA SHA1 I was able to find was below this heading: EcdsaParams (this is passed in SubtleCrypto).

Warning: SHA-1 is also supported here but the SHA-1 algorithm is considered vulnerable and should no longer be used.

We don't seem to track other specific information about supported algorithms, so I don't think there is anything here to do. I guess we might change that note to

Warning: SHA-1 may be supported in some browsers but the SHA-1 algorithm is considered vulnerable and should not be used even if supported.

Can you confirm?

Comment 15

[Darkspirit]

(In reply to Hamish Willee from comment #14)
This has nothing to do with WebCrypto. This is only about TLS (https).
MDN was never that precise. A handshake signature is not something that regular web developers can configure in their web server.
Firefox' client-side ciphersuites don't seem to be officially documented.
There is only a recommendation for servers: https://wiki.mozilla.org/Security/Server_Side_TLS
This page is just a general overview: https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security
I don't really know what dev-doc-needed should mean other than an "Intent to Unship: ECDSA CBC ciphersuites and ECDSA_SHA1 handshake signature" (text: Firefox deprecates the same as Chromium.) email in Google Groups? A decision maker should do that if it's appropriate.
https://wiki.mozilla.org/ExposureGuidelines#Intent_to_unship
https://groups.google.com/a/mozilla.org/g/dev-platform