486371 - getpersonas.com should be served using SSL

Status: RESOLVED WONTFIX

(Websites Graveyard :: getpersonas.com, defect, P2)

Description

[:Gavin Sharp [email: [e-mail]]]

Two separate issues here, but both would be fixed by moving getpersonas.com over to SSL:

1) The addon installation itself is insecure (no SSL or hash passed to InstallTrigger)

2) The "preview a persona" feature allows a man-in-the-middle attacker to control your browsers appearance, since access to the feature does not require SSL.

The odds of either of these issues posing a problem in practice are relatively low, and the cost of hosting the site on SSL in terms of resources may be prohibitive in the short term, but if the site's popularity remains high the odds of it becoming a target shouldn't be discounted. We go to a lot of trouble to protect AMO users from threats like these, so it would be a good idea to extend that protection to GetPersonas.com users.

Comment 1

[Chris Beard]

thanks for looking into this. relevant questions/comments:

1) while the landing page is not SSL, all other pages on the install path are. we're installing the add-on by loading a separate web page (https://addons.mozilla.org/services/install.php?addon=personas) that then redirects -- but only if the referrer is getpersonas.com -- and starts the XPI install (https://addons.mozilla.org/en-US/firefox/downloads/latest/10900)

does having the download link be on a non-SSL site introduce a security risk?

if so, there are many other download pages we're going to need to fix (e.g. ebay companion for firefox)

2) agree that this is an issue, but a minor one given the functionality is not tied to installing anything or making any destructive changes. i suspect the bigger issue is that the JSON feed is not being served up over SSL. it looks like that changed sometime within the last release cycle.

Comment 2

[matthew zeier [:mrz]]

> The odds of either of these issues posing a problem in practice are relatively
> low, and the cost of hosting the site on SSL in terms of resources may be
> prohibitive in the short term, 

It's something to consider for the long term.  Short-term, this won't induce any additional SSL load that we can't already handle.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Yeah, I was aware of the new download link when I filed this bug. The remaining risk is that the front page itself gets man-in-the-middled, in which case it could change the download link to point anywhere. Granted, that risk is always present to some degree, since typing "getpersonas.com" into the address bar defaults to http, but at least in that case there would be a lack of SSL status indicators (or a bogus redirected-to URL) to potentially clue users in to the attack, especially if they're in the habit of getting all-SSL by default.

Even after typing all that, I'm somewhat more ambivalent about 1) than I was when I filed the bug, though. The risk of this posing a problem in practice is probably pretty low. 2) on the other hand would be a neat hack :)

(In reply to comment #2)
> It's something to consider for the long term.  Short-term, this won't induce
> any additional SSL load that we can't already handle.

I was actually thinking more of admin/setup overhead (obtaining/setting up the cert, switching over links, etc.), but if it's not much trouble to set up maybe the cost/benefit ratio is lower than I thought! You guys are in the better position to make that call anyways.

Comment 4

[matthew zeier [:mrz]]

(In reply to comment #3)
> Yeah, I was aware of the new download link when I filed this bug. The remaining
> risk is that the front page itself gets man-in-the-middled, in which case it
> could change the download link to point anywhere. 

We should be equally or even more concerned about getfirefox.com and I haven't heard anyone mention that.

(I'm not arguing for or against this)

Comment 5

[Toby Elliott [:telliott]]

Yeah, I mean I agree with Gavin in principle, but on the level of everything-should-be-SSL. As ease of abuse/potential value ratios go, the site is pretty slim pickings.

I'd be more concerned from a performance standpoint. The images already come back a little slow sometimes, and adding an ssl wrapper to all of that isn't going to improve things.

Comment 6

[matthew zeier [:mrz]]

Modern computers are fast and SSL computations aren't that big of a deal.  Compare AMO to getpersonas - the former isn't significantly slower to load.

Comment 7

[Ryan Doherty (:rdoherty)]

wontfixing due to low activity and getpersonas.com is moving to AMO, which is served via SSL.