Closed
Bug 627596
Opened 12 years ago
Closed 12 years ago
Move about:home snippets url to https
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
FIXED
Firefox 4.0b12
Tracking | Status | |
---|---|---|
blocking2.0 | --- | .x+ |
People
(Reporter: mak, Assigned: johnath)
Details
(Whiteboard: [about-home])
Attachments
(1 file, 1 obsolete file)
1.86 KB,
patch
|
Details | Diff | Splinter Review |
This was brought up during the security review and should most likely be a hardblocker for the release. * snippet URL in product/pref needs to be SSL * about:home itself should reject any URL not "https://" * make sure domain is *.mozilla.org also? - if so need an "out" for non-Firefox products. current version of the page uses a non secure source and has no constraint. For backwards compatibility most likely webdev/IT can setup a redirect from the http:// source to the https:// source (there should be no security error in doing this on the same domain) I'm hiding the bug for now, if it's not needed, please fix it.
Reporter | ||
Updated•12 years ago
|
blocking2.0: --- → ?
Comment 1•12 years ago
|
||
I'm very happy to see this issue being addressed. Thanks to those in the security review for mentioning this as a valid issue. Considering I first mentioned this problem in the original implementation bug on 2010-09-03 (bug 563738, comment #10), I don't think this needs to be hidden.
Comment 2•12 years ago
|
||
...and as comments 15 and 16 in that bug, the risk with about:home not using SSL is no different than the risk from the current non-SSL google.com/firefox start page. Has anything changed? Good the we have a bug on file, and we should definitely do this, but I don't see this being a hardblocker (or even blocker) based on current info.
Comment 3•12 years ago
|
||
(In reply to comment #0) > current version of the page uses a non secure source and has no constraint. For > backwards compatibility most likely webdev/IT can setup a redirect from the > http:// source to the https:// source (there should be no security error in > doing this on the same domain) snippets.mozilla.com doesn't even exist right now, so there's no need for a redirect. I'm curious if it should probably be renamed to snippets.mozilla.org, though, to match the new URL scheme being used...
Group: core-security
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to comment #2) > ...and as comments 15 and 16 in that bug, the risk with about:home not using > SSL is no different than the risk from the current non-SSL google.com/firefox > start page. Has anything changed? the added risk is because we give a local page that user can trust to (the location bar shows a safe address like a about: page) but content is injected without giving user any idea of where it comes from. Spoofing google.com/firefox the new address would appear in the location bar, at least. I mostly filed this based on the request of the security team to fix this before the release.
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to comment #3) > snippets.mozilla.com doesn't even exist right now, so there's no need for a > redirect. if we fix this bug and we want to produce snippets able to reach users of beta7+ we'll need it.
Assignee | ||
Comment 6•12 years ago
|
||
(In reply to comment #4) > the added risk is because we give a local page that user can trust to (the > location bar shows a safe address like a about: page) but content is injected > without giving user any idea of where it comes from. Spoofing > google.com/firefox the new address would appear in the location bar, at least. > I mostly filed this based on the request of the security team to fix this > before the release. A spoofing attack against the old home page would not change the location bar display (the attacker would just spoof the domain) and I don't really believe that users accord one url or the other substantially more trust. I'll all for delivering the snippets over ssl, to be clear. But to accept it as a hard blocker, I need a better understanding of what differential attack we see, as dolske notes in comment 2. We also really need webdev and maybe engagement on this thread - the change product side is just a pref.
Reporter | ||
Comment 7•12 years ago
|
||
(In reply to comment #6) > the change > product side is just a pref. and a added check that the pref points to a https
Comment 8•12 years ago
|
||
One thing to consider is bug 603674. That was filed to let us point the browser at an URL other than the production snippets service, thus facilitating: a) testing and QA on the snippets service itself and b) testing and QA for snippets in the future on a content staging site So, if additional restrictions are enforced, I hope we can still accommodate those concerns.
Comment 9•12 years ago
|
||
(In reply to comment #3) > snippets.mozilla.com doesn't even exist right now, so there's no need for a > redirect. Not for lack of trying, see bug 592431.
Comment 10•12 years ago
|
||
(In reply to comment #8) > One thing to consider is bug 603674. That was filed to let us point the browser > at an URL other than the production snippets service Oh, and by "other than production", I mean base URLs like: * http://localhost:8000/ (ie. dev server on my laptop) * http://lorchard.khan/ (ie. a server running on a webdev machine inside Mozilla) * https://snippets.stage.mozilla.com/ (ie. staging server, running now) Enforcing https would be a speed bump for development on my laptop, and I could probably set an /etc/hosts entry to account for a domain restriction. But, that's only if the domain restriction is flexible enough
Reporter | ||
Comment 11•12 years ago
|
||
(In reply to comment #10) > Enforcing https would be a speed bump for development on my laptop, and I could > probably set an /etc/hosts entry to account for a domain restriction. But, > that's only if the domain restriction is flexible enough there is no clear plan for domain restriction, and as you said a hosts change can easily bypass any domain restriction. Most likely the only valuable plan here is forcing https
Comment 12•12 years ago
|
||
As per comment 6, not blocking, but as soon as the IT systems want us to flip the http to an https, we'll do it.
blocking2.0: ? → .x
Comment 13•12 years ago
|
||
The production service doesn't yet exist. What's the tradeoff of switching the in-product URL not vs. later?
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to comment #13) > The production service doesn't yet exist. What's the tradeoff of switching the > in-product URL now vs. later? Can happen any time. Zero code risk, url includes "insert current locale here" magic so there's no client-side string impact either. Can happen in point releases.
Assignee | ||
Comment 15•12 years ago
|
||
Justin says the decision is to do HTTPS, this should do it, but wanted to get mak's signoff in case this surprises any tests.
Attachment #508988 -
Flags: review?(mak77)
Reporter | ||
Comment 16•12 years ago
|
||
Comment on attachment 508988 [details] [diff] [review] Flip to https I think the point of the request, apart updating the pref was to add a simple check in aboutHome.js that updateURL has a https schema?
Reporter | ||
Comment 17•12 years ago
|
||
Btw, right now we don't have a test for remote snippets loading, there is a test for default snippets, that this change doesn't touch.
Comment 18•12 years ago
|
||
Site's not yet up (and DNS isn't yet setup) but it will be at 63.245.217.43.
Assignee | ||
Comment 19•12 years ago
|
||
(In reply to comment #17) > Btw, right now we don't have a test for remote snippets loading, there is a > test for default snippets, that this change doesn't touch. Hmm - what value does that add? The threat model here is a MitM attacker, right? That model is mitigated by just fixing the default pref. If the threat model is someone able to change prefs in the client to specify a different URL, then I don't think a check mitigates anything there. Not that such a check is hard to implement, but it's extra logic and I don't really see it serving a purpose. Can someone from the security team comment on that, or do you know more in terms of justification, Marco? Otherwise, I think we should take the pref change and we can file a follow up around the check if there's good reason to do so.
Reporter | ||
Comment 20•12 years ago
|
||
(In reply to comment #19) > Not that such a check is hard to implement, but it's extra logic and I don't > really see it serving a purpose. Can someone from the security team comment on > that, or do you know more in terms of justification, Marco? Well, https source must have a valid certificate, at least, and can't be "downgraded" to unsecure. I reported the same doubts about the usefulness of the check, the conclusions are in the security bug review comments part: 'about:home itself should reject any URL not "https://"'. I'm not a security expert, so I can't tell more about something that I could be missing. The patch is fine, but we still need feedback from the security team if we implement half of the requests I think.
Reporter | ||
Updated•12 years ago
|
Attachment #508988 -
Flags: review?(mak77) → review+
Comment 21•12 years ago
|
||
(In reply to comment #19) > Hmm - what value does that add? The threat model here is a MitM attacker, > right? That model is mitigated by just fixing the default pref. If the threat > model is someone able to change prefs in the client to specify a different URL, > then I don't think a check mitigates anything there. The worry was that future not-Firefox distributors would be stupid and not understand the value of a TLS url for these snippets. Documenting the value of TLS where the pref is set (and maybe in the code near where it's read?) is good enough.
Assignee | ||
Comment 22•12 years ago
|
||
Now with comment! This should be good to checkin, and matches my conversations with members of the security team
Attachment #508988 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Keywords: checkin-needed
Reporter | ||
Comment 24•12 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/84c5a8661d9c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Reporter | ||
Updated•12 years ago
|
Summary: Force about:home to use a secure source for snippets → Move about:home snippets url to https
Reporter | ||
Updated•12 years ago
|
Whiteboard: [about-home]
You need to log in
before you can comment on or make changes to this bug.
Description
•