Closed Bug 1330043 Opened 7 years ago Closed 7 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
relnote-firefox --- -
firefox52 --- fixed
firefox-esr52 --- fixed
firefox53 --- fixed

People

(Reporter: keeler, Assigned: keeler)

References

Details

(Keywords: dev-doc-complete, site-compat, Whiteboard: [psm-assigned])

Attachments

(2 files)

I have come here to chew bubblegum and disable sha1. And I'm all out of bubblegum.
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.
Attachment #8825938 - Flags: review?(jjones) → review+
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/75a82021c03e
disable SHA-1 in signatures on certificates issued by publicly-trusted roots r=jcj
Matt, this is definitely a change we'll want a canary run on after it lands and you get a chance. Thanks!
Flags: needinfo?(mwobensmith)
Patch landed few hours ago https://hg.mozilla.org/mozilla-central/rev/75a82021c03e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
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.
Flags: needinfo?(mwobensmith)
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.
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...)
For reference, it seems that this is also biting meetme.com.
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/
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?
Flags: needinfo?(mwobensmith)
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/
Flags: needinfo?(mwobensmith)
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
Flags: needinfo?(jjones)
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.
Flags: needinfo?(jjones) → needinfo?(kohei.yoshino)
Thanks :jcj, just updated the compat note.
Flags: needinfo?(kohei.yoshino)
(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).
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 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
Attachment #8825938 - Flags: approval-mozilla-beta?
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
Attachment #8825938 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I've added a note about this to the Fx53 release notes:

https://developer.mozilla.org/en-US/Firefox/Releases/53#Security
(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.
Flags: needinfo?(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
Flags: needinfo?(cmills)
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: