1330043 - disable sha1 in signatures on certificates issued by publicly-trusted roots

Status: RESOLVED FIXED

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

Description

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

I have come here to chew bubblegum and disable sha1. And I'm all out of bubblegum.

Comment 1

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

Attachment: bug 1330043 - disable SHA-1 in signatures on certificates issued by publicly-trusted roots

Unfortunately, this doesn't cover delegated OCSP responder certificates. While
gathering telemetry on the use of SHA-1, we encountered bug 1183822 (basically,
that the method of gathering telemetry was causing OCSP verification failures
due to delegated responders signed with SHA-1). As a temporary solution, we
changed the verifier to always allow SHA-1 for OCSP certificates when verifying
an OCSP response. Consequently, we now have no idea what the compatibility
impact of disabling SHA-1 in OCSP responder certificates will be, so it's
probably not a good idea to do that right now.

Even if someone does manage to forge an OCSP responder certificate using a SHA-1
collision, they will have about as much power as an active network attacker
blocking OCSP requests or injecting bad stapled OCSP responses, so this isn't a
disaster.

Review commit: https://reviewboard.mozilla.org/r/103998/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/103998/

Comment 2

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

Comment on attachment 8825938 [details]
bug 1330043 - disable SHA-1 in signatures on certificates issued by publicly-trusted roots

https://reviewboard.mozilla.org/r/103998/#review104742

Looks good to me.

Comment 3

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

Thanks!
https://treeherder.mozilla.org/#/jobs?repo=try&revision=05217a19dbbfd352a86e1b1ec60c03107e676281

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/75a82021c03e
disable SHA-1 in signatures on certificates issued by publicly-trusted roots r=jcj

Comment 5

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

Matt, this is definitely a change we'll want a canary run on after it lands and you get a chance. Thanks!

Comment 6

[Guilherme Lima]

Patch landed few hours ago https://hg.mozilla.org/mozilla-central/rev/75a82021c03e

Comment 7

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

Attachment: fx53_sha1_broken_sites.txt

I see about ~1100 regressions for this change. See attachment for site list and rank.

The run is viewable here:

https://tlscanary.mozilla.org/runs/2017-01-16-17-00-59

Ignore the other errors for now. Those are from bug 1317857 and bug 1309707.

Comment 8

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

I've checked the first 10: All but https://www.dmoz.org are also broken in Chrome Canary, as we would expect. Dmoz seems to be presenting a SHA-2 certificate to me.

Comment 9

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

Looks like it's sending this intermediate: https://crt.sh/?id=307 (signed with sha-1)
Presumably there's a replacement? We could reach out to them to update their setup. (We could also potentially identify common sha-1 intermediates that have a sha-2 replacement and ship them with the browser...)

Comment 10

[Thomas Wisniewski]

For reference, it seems that this is also biting meetme.com.

Comment 11

[Kohei Yoshino]

My site compat doc [1] was written for Firefox 51 but apparently wrong. Correcting the affected version.

[1] https://www.fxsitecompat.com/en-CA/docs/2016/sha-1-certificates-issued-by-public-ca-will-no-longer-be-accepted/

Comment 12

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

Matt: Chrome 56 released two weeks ago with their equivalent change in place, so SHA-1 is deprecated for all Chrome users. Could you re-run the TLS Canary for us, to see how many sites have fixed themselves in the last two weeks?

Comment 13

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

We have seen a roughly 17% drop in broken sites in the past two weeks or so, among top sites examined.

Date, SHA1 breakage (out of ~290k sites):
2017-02-09, 1058
2017-01-27, 1262

Latest run is here:
https://tlscanary.mozilla.org/runs/2017-02-09-20-13-01/

Comment 14

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

Looking further into that run, I'm noticing that not all breakage is due to sites with SHA1-encoded EE certs. Some broken sites' EE certs are SHA256-encoded, but have intermediate certs encoded with SHA1.

Some sites [1] - just a sampling, there are more - break in Fx Nightly, but work on Fx release, as well as Chrome. All of them fit the criteria above. If these sites break in Fx Nightly but not Chrome, should we be alarmed? 


[1]
https://www.uni-freiburg.de
https://www.uksh.de
https://www.tjnp.gov.tw
https://www.tc.edu.tw
https://www.tbs-sct.gc.ca
https://www.swcz.de
https://www.studentenwerk-magdeburg.de
https://www.spnp.gov.tw
https://www.preussischer-kulturbesitz.de
https://www.oninet.ne.jp

Comment 15

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

This is due to Chrome doing AIA-chasing, while Firefox does not. That's part of the risk we're concerned about, that sites are serving invalid chains but can get away with it with Chrome and Edge.

Kohei - perhaps we should update the site-compat to note that intermediates may need to be updated as well, if the issuing CA has re-issued them in recent years.

Comment 16

[Kohei Yoshino]

Thanks :jcj, just updated the compat note.

Comment 17

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

(In reply to J.C. Jones [:jcj] from comment #15)
> This is due to Chrome doing AIA-chasing, while Firefox does not. That's part
> of the risk we're concerned about, that sites are serving invalid chains but
> can get away with it with Chrome and Edge.

One thing we could do is attempt to identify a set of intermediates that have been reissued but where sites are commonly sending the old SHA-1 versions and ship them with the browser (this could even be done in a go-faster add-on).

Comment 18

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

Error reporting data shows no uptick in volume since we've turned things on via system addons [1].

Per the SHA-1 deprecation schedule [2], I think this is ready to request uplift approval into Beta.

[1] https://i.have.insufficient.coffee/deprecation-20170221.png
[2] https://wiki.mozilla.org/Security/CryptoEngineering/SHA-1#Planned_Sampled_Rollout_Timeline

Comment 19

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

Comment on attachment 8825938 [details]
bug 1330043 - disable SHA-1 in signatures on certificates issued by publicly-trusted roots

Per Comment 18 and the SHA-1 deprecation plan approved by release-drivers, we're requesting beta uplift for the preference change now that we've validated via Go Faster.

Approval Request Comment
[Feature/Bug causing the regression]: N/A
[User impact if declined]: Prolonged exposure to the insecure SHA-1 algorithm; it's disabled in 53. 
[Is this code covered by automated tests?]: Yes, and has been rolled out already via Go Faster.
[Has the fix been verified in Nightly?]: Yes, and in Beta via Go Faster.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: This is making a code preference change to catch-up to the Go Faster addon's 100% change
[String changes made/needed]: None

Comment 20

[Julien Cristau [:jcristau]]

Comment on attachment 8825938 [details]
bug 1330043 - disable SHA-1 in signatures on certificates issued by publicly-trusted roots

goodbye sha1, it was nice knowing you

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3aaf82595ea5

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/3aaf82595ea5

Comment 23

[Chris Mills [:cmills]]

I've added a note about this to the Fx53 release notes:

https://developer.mozilla.org/en-US/Firefox/Releases/53#Security

Comment 24

[Daniel C]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #23)
> I've added a note about this to the Fx53 release notes:
> 
> https://developer.mozilla.org/en-US/Firefox/Releases/53#Security

This was actually released in Firefox 52. The tracking flags reflect that but the Target doesn't look like it was updated.

Comment 25

[Chris Mills [:cmills]]

(In reply to Daniel Cater from comment #24)
> (In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #23)
> > I've added a note about this to the Fx53 release notes:
> > 
> > https://developer.mozilla.org/en-US/Firefox/Releases/53#Security
> 
> This was actually released in Firefox 52. The tracking flags reflect that
> but the Target doesn't look like it was updated.

Cool, thanks for the heads up! I've moved it to the 52 notes:

https://developer.mozilla.org/en-US/Firefox/Releases/52#Security

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds like we noted this on MDN for 52 and don't need to mention it in the main release notes for 53 and onwards.