627596 - Move about:home snippets url to https

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Marco Bonardo [:mak] (Away July 4-13)]

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.

Comment 1

[Reed Loden [:reed]]

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

[Justin Dolske [:Dolske]]

...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

[Reed Loden [:reed]]

(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...

Comment 4

[Marco Bonardo [:mak] (Away July 4-13)]

(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.

Comment 5

[Marco Bonardo [:mak] (Away July 4-13)]

(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.

Comment 6

[Johnathan Nightingale [:johnath]]

(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.

Comment 7

[Marco Bonardo [:mak] (Away July 4-13)]

(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

[Les Orchard [:lorchard]]

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

[Les Orchard [:lorchard]]

(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

[Les Orchard [:lorchard]]

(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

Comment 11

[Marco Bonardo [:mak] (Away July 4-13)]

(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

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 13

[matthew zeier [:mrz]]

The production service doesn't yet exist.  What's the tradeoff of switching the in-product URL not vs. later?

Comment 14

[Johnathan Nightingale [:johnath]]

(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.

Comment 15

[Johnathan Nightingale [:johnath]]

Attachment: Flip to https

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.

Comment 16

[Marco Bonardo [:mak] (Away July 4-13)]

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?

Comment 17

[Marco Bonardo [:mak] (Away July 4-13)]

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

[matthew zeier [:mrz]]

Site's not yet up (and DNS isn't yet setup) but it will be at 63.245.217.43.

Comment 19

[Johnathan Nightingale [:johnath]]

(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.

Comment 20

[Marco Bonardo [:mak] (Away July 4-13)]

(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.

Comment 21

[Daniel Veditz [:dveditz]]

(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.

Comment 22

[Johnathan Nightingale [:johnath]]

Attachment: Add comment

Now with comment! This should be good to checkin, and matches my conversations with members of the security team

Comment 23

[Marco Bonardo [:mak] (Away July 4-13)]

nice, thanks!

Comment 24

[Marco Bonardo [:mak] (Away July 4-13)]

http://hg.mozilla.org/mozilla-central/rev/84c5a8661d9c