Closed Bug 627596 Opened 10 years ago Closed 10 years ago

Move about:home snippets url to https

Categories

(Firefox :: General, defect)

defect
Not set
normal

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)

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.
blocking2.0: --- → ?
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.
...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.
(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
(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.
(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.
(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.
(In reply to comment #6)
> the change
> product side is just a pref.

and a added check that the pref points to a https
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.
(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.
(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
(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
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
The production service doesn't yet exist.  What's the tradeoff of switching the in-product URL not vs. later?
(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.
Attached patch Flip to https (obsolete) — Splinter Review
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)
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?
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.
Site's not yet up (and DNS isn't yet setup) but it will be at 63.245.217.43.
(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.
(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.
Attachment #508988 - Flags: review?(mak77) → review+
(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.
Attached patch Add commentSplinter Review
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
Keywords: checkin-needed
nice, thanks!
Assignee: nobody → johnath
Status: NEW → ASSIGNED
http://hg.mozilla.org/mozilla-central/rev/84c5a8661d9c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Summary: Force about:home to use a secure source for snippets → Move about:home snippets url to https
Whiteboard: [about-home]
You need to log in before you can comment on or make changes to this bug.