1129083 - Remove support for certificates signed using SHA-512-based signatures

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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

Firefox's TLS handshake advertises support for ECDSA and RSA in combination with SHA-1, SHA-256, and SHA-384. Firefox doesn't advertise support for SHA-512. MSIE and Chrome are similar; see [2] and [3].

A good discussion of SHA-384 vs SHA-512 is at http://stackoverflow.com/questions/10061532/why-chose-sha512-over-sha384. In general, there's no need to use SHA-512 over SHA-384, and in fact SHA-384 is almost always better (if only because the output is smaller). Note that length extension attacks don't apply to the use of hash functions in signature verification, which is what's relevant as far as certificates are concerned.

Kathleen: The CA policy documents [1] mention SHA-512. We should remove that reference from the CA policy.

[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
[2] https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%2010%20Preview
[3] https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=39&platform=OS%20X

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Remove SHA-512 support

Comment 2

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

I have compatibility concerns about this. Just looking at certificates in the certificate transparency log, many signatures use sha-512 (and unfortunately we don't have telemetry data like we do with p521). I understand that the p521 implementation was potentially problematic, but are there similar concerns with sha-512? In other words, what's the win here?

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #2)
> I have compatibility concerns about this. Just looking at certificates in
> the certificate transparency log, many signatures use sha-512 (and
> unfortunately we don't have telemetry data like we do with p521). I
> understand that the p521 implementation was potentially problematic, but are
> there similar concerns with sha-512? In other words, what's the win here?

1. I explained some of the reasoning in bug 1130580. Basically, it doesn't make sense to use a SHA-512 and P-384 together, nor does it make sense to use SHA-384 or SHA-512 and P-256 together, and I'd like to avoid any potential (unknown) problems caused by that nonsense. This only applies to ECDSA though, not RSA.

2. Like I mentioned above, Firefox's TLS handshake doesn't advertise support for SHA-512 signatures, only SHA-384, SHA-256, and SHA-1 signatures. MSIE and Chrome do the same. I'd like to make the values in TLS supported curves extension match what is actually supported, if reasonable.

3. Note that in bug 610162, in November *2010*, I fixed a bug in NSS where NSS was calculating SHA-512 (and SHA-384) digests incorrectly. That's some evidence that the "limitation of attach surface" argument applies here, too, though it's not a very strong argument since SHA-384 uses the same code.

An alternative course of action would be, for example, to stop supporting SHA-512 signatures for ECDSA and to change Gecko's TLS handshake to advertise support for RSA-SHA512. Other courses of action are also possible.

In the data you looked at, how many of the SHA-512 signatures were ECDSA and how many were RSA? And, how many is "many"?

Comment 4

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

I found around 2800 certificates signed with SHA512WithRSA, but when filtering on certificates that are likely to validate correctly with Mozilla's roots, the number dropped to 12. I found 0 certificates signed with ECDSAWithSHA512. I found 11 certificates signed with ECDSAWithSHA384 that are likely to validate correctly with Mozilla's roots. As an aside, I found 14 certificates that appeared to have P-521 keys that are likely to validate under Mozilla's roots.

(These numbers aren't exactly definitive - certificate transparency is unfortunately a small subset of what's actually in the ecosystem.)

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

David, did you build a web interface for searching the CT data? If so, can I get access to it?

And/or, can you attach the list of SHA-512-using certificates (or just the domain names) from the CT database to this bug? It would be useful for me to understand this issue.

Thanks!

Comment 6

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

Unfortunately there's not a generic web interface for the CT data yet. It is something I've been thinking about, though.
Here's the list of common names (looks like there are two duplicates):

*.clintwilson.technology
*.clintwilson.technology
ajax.deskapi.com
*.assistly.com
*.desk.com
homsar.uvt.nl
www.thinklamar.com
chart.myunitypoint.org
carelink.unitypoint.org
*.wilsonovi.com
*.wilsonovi.com
sunapsis.byuh.edu

I found live SHA-512 certs at all of them except the first. They appear to be issued by DigiCert, so maybe we could reach out to them.

Comment 7

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

Comment on attachment 8558677 [details] [diff] [review]
Remove SHA-512 support

I think this looks fine, but I'm going to cancel review for now, pending the results of bug 1130653.

Comment 8

[Julien Vehent]

The TLS Observatory could help answer this, but I only have a limited subset of the data right now. It will take a few days until all of Alexa's top 1M is scanned.

Regardless, on a pool of ~50,000 certificates, only 38 use SHA512WithRSA, none of which are trusted by NSS.

Dashboard link:
http://tls.opsec.allizom.org/#/dashboard/NSS-non-CAs?_a=%28filters:!%28%29,panels:!%28%28col:4,row:1,size_x:5,size_y:3,visId:Signature-Algorithm-by-NSS-trust%29,%28col:9,row:1,size_x:4,size_y:3,visId:Public-Key-Algorithm-by-NSS-trust%29,%28col:4,row:4,size_x:5,size_y:3,visId:RSA-Modulus-Size-by-NSS-trust%29,%28col:9,row:4,size_x:4,size_y:3,visId:ECDSA-Curve-by-NSS-trust%29,%28col:1,row:1,size_x:3,size_y:3,visId:NSSCertsTrustedCount%29%29,query:%28query_string:%28query:%27*%27%29%29,title:%27NSS%20non-CAs%27%29&_g=%28time:%28from:now-12y,mode:relative,to:now%29%29

To limit the display to SHA512 signed certs, add this filter: signatureAlgorithm:*sha512*

Comment 9

[Julien Vehent]

The observer collected around 250,000 certificates from Alexa's top 1M, and the only valid SHA512 cert it could find belongs to tmmid.com
http://tls.opsec.allizom.org/#/doc/certificates/certificates/certificateInfo/FF3A6D50C629E5863961FECCF2AFA641DD54285A84DF8A3CF9BA5FFDC1CD70F2
There are a few hundreds more SHA512 certs, almost exclusively RSA, but no other validates against NSS's truststore.

Comment 10

[Vitaly L. Fadeev]

This bug related only to ECDSA?
I have RSA cert signed with SHA-512.
Thunderbird doesnt works with my server.

Comment 11

[jasonmc]

I would ask that not only should SHA512 support not be removed since it is part of the spec and as there are those who use it for (large) internal CA structures, but that Firefox be updated for interoperability purposes. I've been having an ongoing dialog with Microsoft SCHannel developers as to why Microsoft IIS + Firefox 38 trips over the TLS downgrade block when using a certificate chain with SHA512 structures. What appears to be the case is that Microsoft is very strictly interpreting RFC5246 7.4.2 and refusing to use a compatible signature for its cipher selection if the certificates are using SHA512withRSA. Firefox, in its ClientHello message, is not explicitly listing SHA512 in the signature_algorithms section of the request. IIS is then acting as if it cannot properly negotiate a cipher switch and sends back an RST to force another negotiation attempt. This is causing the client to downgrade to TLS 1.1 or TLS 1.0 (I've seen both and haven't figured out what conditions cause which) upon which the same cipher that should have been chosen/negotiated in the TLS 1.2 is being selected. Microsoft claims this is due to signature_algorithms not advertising explicit support for SHA512/{RSA,ECDSA,DCA}. Contrast this behavior with Apache which will choose the use of SHA256 even in the presence of a SHA512 certificate.

If this isn't the right bug to request proper announcement of the signature_algorithms supported in the ClientHello packet, please let me know and I'll file a different bugzilla request.

Comment 12

[jasonmc]

Oh, I forgot to mention that IE does in fact advertise SHA512 for both RSA and ECDSA in the signature_algorithms section of the ClientHello, at least in IE11. It was mentioned above that IE was omitting it.

Comment 13

[:Cykesiopka]

(In reply to jasonmc from comment #11)
> I would ask that not only should SHA512 support not be removed since it is
> part of the spec and as there are those who use it for (large) internal CA
> structures, but that Firefox be updated for interoperability purposes. I've
> been having an ongoing dialog with Microsoft SCHannel developers as to why
> Microsoft IIS + Firefox 38 trips over the TLS downgrade block when using a
> certificate chain with SHA512 structures. What appears to be the case is
> that Microsoft is very strictly interpreting RFC5246 7.4.2 and refusing to
> use a compatible signature for its cipher selection if the certificates are
> using SHA512withRSA. Firefox, in its ClientHello message, is not explicitly
> listing SHA512 in the signature_algorithms section of the request. IIS is
> then acting as if it cannot properly negotiate a cipher switch and sends
> back an RST to force another negotiation attempt. This is causing the client
> to downgrade to TLS 1.1 or TLS 1.0 (I've seen both and haven't figured out
> what conditions cause which) upon which the same cipher that should have
> been chosen/negotiated in the TLS 1.2 is being selected. Microsoft claims
> this is due to signature_algorithms not advertising explicit support for
> SHA512/{RSA,ECDSA,DCA}. Contrast this behavior with Apache which will choose
> the use of SHA256 even in the presence of a SHA512 certificate.
> 
> If this isn't the right bug to request proper announcement of the
> signature_algorithms supported in the ClientHello packet, please let me know
> and I'll file a different bugzilla request.

FWIW, this is fixed on Firefox 39 and above - see Bug 1155932 comment 4.

Comment 14

[jasonmc]

(In reply to Cykesiopka from comment #13)
> (In reply to jasonmc from comment #11)
> FWIW, this is fixed on Firefox 39 and above - see Bug 1155932 comment 4.

This is great news, thanks. Solves a major headache we've been having as well as other people. I think this is one of the problems that InCommon had with their SHA-512 intermediate so hopefully some of these interop issues are being put to bed as people seek to use strong certificates with TLS 1.2.