Closed
Bug 1330043
Opened 8 years ago
Closed 8 years ago
disable sha1 in signatures on certificates issued by publicly-trusted roots
Categories
(Core :: Security: PSM, defect, P1)
Core
Security: PSM
Tracking
()
RESOLVED
FIXED
mozilla53
People
(Reporter: keeler, Assigned: keeler)
References
Details
(Keywords: dev-doc-complete, site-compat, Whiteboard: [psm-assigned])
Attachments
(2 files)
59 bytes,
text/x-review-board-request
|
jcj
:
review+
jcristau
:
approval-mozilla-beta+
|
Details |
25.33 KB,
text/plain
|
Details |
I have come here to chew bubblegum and disable sha1. And I'm all out of bubblegum.
Comment hidden (mozreview-request) |
Comment 2•8 years ago
|
||
mozreview-review |
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+
Assignee | ||
Comment 3•8 years ago
|
||
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
Assignee | ||
Comment 5•8 years ago
|
||
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)
Comment 6•8 years ago
|
||
Patch landed few hours ago https://hg.mozilla.org/mozilla-central/rev/75a82021c03e
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox53:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment 7•8 years ago
|
||
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)
Comment 8•8 years ago
|
||
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.
Assignee | ||
Comment 9•8 years ago
|
||
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•8 years ago
|
||
For reference, it seems that this is also biting meetme.com.
Comment 11•8 years ago
|
||
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/
Keywords: dev-doc-needed,
site-compat
Comment 12•8 years ago
|
||
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)
Comment 13•8 years ago
|
||
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)
Comment 14•8 years ago
|
||
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
Updated•8 years ago
|
Flags: needinfo?(jjones)
Comment 15•8 years ago
|
||
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)
Assignee | ||
Comment 17•8 years ago
|
||
(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•8 years ago
|
||
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•8 years ago
|
||
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 20•8 years ago
|
||
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+
Comment 21•8 years ago
|
||
bugherder uplift |
status-firefox52:
--- → fixed
Comment 22•8 years ago
|
||
bugherder uplift |
status-firefox-esr52:
--- → fixed
Updated•8 years ago
|
relnote-firefox:
--- → ?
Comment 23•8 years ago
|
||
I've added a note about this to the Fx53 release notes:
https://developer.mozilla.org/en-US/Firefox/Releases/53#Security
Keywords: dev-doc-needed → dev-doc-complete
Comment 24•8 years ago
|
||
(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)
Comment 25•8 years ago
|
||
(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)
Comment 26•8 years ago
|
||
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.
Description
•