310355 - Provide the user with better indicators of how secure the xpi install is (signed, https, hashed)

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, enhancement)

Description

[Robert Strong (they/them - no direct email)]

Bug 302284 added the ability to pass a hash to InstallTriigger. I believe it may
be appropriate to display that the file will be verified against the hash in the
xpinstall dialog for 2.0

Comment 1

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

If I'm reading bug 302284 right (and I like to think I am!) then what we're
saying is that there's now a mechanism that allows us to know if an extension
has made it to the client without tampering.

Do we have any sense of how many extensions will end up using this mechanism? I
think the way I'd *rather* do things is visually annotate extensions that have
*not* passed the hash, alerting users to the fact that they may have been
tampered with. Unless, of course, the vast majority won't use hashes.

Comment 2

[Robert Strong (they/them - no direct email)]

Unlike the existing display in the ui that an extension is unsigned in red text
:P this is planned to be implemented on all extensions available from AMO so I
believe the answer is the vast majority of extensions that users will download
will use hashes.

Comment 3

[Jesse Ruderman]

Extensions can be:

A. Signed
B. Unsigned but downloaded using https
C. Unsigned and downloaded using http/ftp and verified using a hash from https
D. Not authenticated in any way

Should the UI treat A, B, and C in the same way?

Comment 4

[Robert Strong (they/them - no direct email)]

I don't think they should be treated in the same way. That would only add more
confusion as to what signing actually provides by confusing signing with
verification of the file against the provided hash. What we have today is a ui
that states unsigned in red letters for the few - probably less than 1% - of
extensions available to users and if this bug is fixed we would be displaying
that the xpi will be verified against the hash for all extensions on AMO when
bug 302287 is fixed as well as any other site that uses InstallTrigger and
provides a hash. I do believe that a warning that is for all practical purposes
always displayed defeats the purpose of having the warning which is the case
with the unsigned warning.

It may be possible for this to occupy the same ui real estate when an extension
isn't signed and if it is signed not display that it will be checksummed
especially if we add the ability to display the details of the cert used for
signing which iirc is already another bug.

Comment 5

[Dave Townsend [:mossop]]

Morphing a little based on comment 3.

Comment 7

[Dave Townsend [:mossop]]

Johnathan, I think you're more appropriate to think about this than Boriss.

Comment 9

[Johnathan Nightingale [:johnath]]

So, let me put out a stupid idea so you can tell me why it's stupid:

We don't signal this at all - it is purely a convenience for authors/addon hosts. It makes life better for our users implicitly since they are less likely to get corrupt/tampered-with data, but they can't make better decisions knowing this than they can not knowing it.

My reasoning is this:

- the hash tells us an addon hasn't been corrupted/tampered-with BUT
- so does https (and it does it in a more generically attack resistant way by not, for instance, accepting MD2 hashes)
- so the assumption here is that we're not using https, because if we were, this added hash check wouldn't add much
- but if we're not using https, then the hash itself, including in the JS of the installing page, is just as subject to tampering as the addon itself
- so this doesn't really buy us anything against a dedicated attacker, it just protects us against accidental corruption

The only case I can think of here is when the addon is delivered over http, but the page which triggers the install (and contains the hash) is delivered over https, maybe because it's cheaper/faster to only host the web content over https. In that one case, this gives us a way to check the legitimacy of the addon, despite being delivered over http.

If we're going to create a different UI experience (and associated code path) for this case, I'd say we need a reason to believe it's common, and that users will make different decisions based on the information.  Is it, and will they? If the argument is that they will, then I agree with beltzner that I'd rather signal the danger state than the a-ok state. But I find it hard to believe that someone who's convinced they want FireWeatherStockTickerFox and has gone through the process to okay the install will then be stopped by "This addon will not be delivered securely."  If we think there's a significant risk there, maybe we shouldn't ask the user to assess it, maybe we should just block unsecured http addon downloads unless a hash has been provided over https?

I told you it might be a stupid idea - what do you think?

Comment 10

[Jesse Ruderman]

I'm inclined to agree with Johnath.

* Seeing where the extension came from is more important than whether that communication was authenticated.

* Most software downloads are not authenticated, which is unfortunate, but why should extensions be special?

Comment 11

[Eddy Nigg (StartCom)]

According to the Mozilla CA Policy, certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf.

This gives us clearly more indications than just protection against corruption and tampering - but who stands behind the code. Even though Mozilla asserts some control over its repository, not all extensions are on addons.mozilla.org. We should protect users from installing key-loggers and other malware, assuming that validated developers are less likely to distribute such software in their name.

Comment 12

[Giorgio Maone [:ma1]]

(In reply to comment #9)

> The only case I can think of here is when the addon is delivered over http, but
> the page which triggers the install (and contains the hash) is delivered over
> https, maybe because it's cheaper/faster to only host the web content over
> https. In that one case, this gives us a way to check the legitimacy of the
> addon, despite being delivered over http.

It's exactly the case of AMO.

> maybe we should just block unsecured http addon downloads 
> unless a hash has been provided over https?

Bug 544660 would have been caught immediately, and anyway impossible to exploit, if such a policy was in effect.

Regarding signed extensions (disclosure: mine are), I believe a double warning for those which are not and/or a more prominent placement of the verified author is needed (even though I suspect is not enough) to make signing more useful. As it is, the difference hardly noticeable, see http://www.carbonwind.net/blog/post/Firefox-Extension-download-process-and-the-mess-within.aspx

Comment 13

[David E. Ross]

Whatever is done, please do NOT over-protect the end user.  

Not all extensions are obtained from AMO.  Even some extensions listed at AMO have their download sites at the author's own domain.  You might implement warnings and even hoops through which users must jump, but a user-oriented method is needed to finally install extensions that are neither hashed, signed, nor from a secure Web site.  

For an example of over-protecting end users, see bug #548380.  If you fail to establish SSL security on a Web page because of a root certificate glitch, you cannot find out what root certificate was glitched or even import the site certificate.  You are just plain dead.

Comment 14

[Alex Limi (:limi) — Firefox UX Team]

I don't think the UX team has anything we can contribute here until it's been decided what we want to do from a security standpoint.

Comment 15

[David E. Ross]

Adding to my comment #13:  

Since I maintain both my own configuration and my wife's and because I want to archive all changes I make to these configurations, I first download the XPI file and then install it from my hard drive.  I log all changes to my configuration.  In order to minimize extraneous changes during the installation from appearing in the log, I disable my Internet connection.  

Thus, whatever is done for this RFE should (1) not require an Internet connection to install an XPI and (2) should not make such an installation more complicated.

Comment 16

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.