Closed Bug 384812 Opened 19 years ago Closed 17 years ago

Don't warn about extension being "unsigned" when it is retrieved over https

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 310355

People

(Reporter: jruderman, Unassigned)

References

(
URL
)

Details

I think that installing an extension using https (e.g. https://addons.mozilla.org/en-US/firefox/addon/234 or https://www.squarefree.com/extensions/thumbs/) such not warn about the extension being unsigned. https seems to be the right kind of security for installing software: you know whose software you're installing, and you know that you're getting the latest version, even if you're using an untrusted internet connection.
I'm not positive what you are suggesting here. Do you just mean the "Unsigned" red text at the right of the install dialog for add-ons coming from https sites?
Right, I just want the red "Unsigned" text to go away for https add-on installations.
I'm not sure why we do this... Encouraging signed extensions would be a good thing, but people already download plenty of unsigned binary software without the browser complaining. And install unsigned extensions, for that matter. :-) We've probably already trained Firefox users that unsigned extensions are A-OK, and to ignore any dialog that says otherwise. :-( I'm tempted to suggest that we treat .xpi installs and executable downloads in a similar manner (SSL or not), and improve the UI to be a bit more practical about the situation. Although that's rather aiming low, and not pushing to make the web a better place...
OS: Mac OS X → All
Hardware: PC → All
(In reply to comment #3) > I'm not sure why we do this... Encouraging signed extensions would be a good > thing, but people already download plenty of unsigned binary software without > the browser complaining. And install unsigned extensions, for that matter. :-) Sure, I think you're exactly right here. But that doesn't mean we can't try to set a higher bar for firefox modifications (via addons) than the rest of the OS does with random binaries. Obviously a random binary could corrupt firefox in arbitrary ways, but that doesn't get us off the hook for cleaning up our own yard. Having said that... > I'm tempted to suggest that we treat .xpi installs and executable downloads in > a similar manner (SSL or not), and improve the UI to be a bit more practical > about the situation. Although that's rather aiming low, and not pushing to make > the web a better place... You already anticipated this line of comment. :) Signing an extension is supposed to be an assertion of identity and non-tampering. Maybe, if we want to be sort of pretend-world for a moment, we could think of it as additionally being an assertion by the signing party that the code is nice, free of malice, etc. But cryptographically, it asserts identity of the signing party and non-tampering of the contents since signing. Sending the update over SSL, particularly a shared service like AMO, provides assurances of non-tampering in transit, and also provides identity, although it's the identity of the server sending you the add on, not necessarily the identity of the person/group creating the add on. Both of these things, identity and non-tampering, may be important to users, even if they can't articulate them as cryptographic principles. When we say that an update is signed in the UI, are we trying to communicate a) that its bits are intact, or b) that we know who built it? If a), we should blank the "Unsigned" UI on SSL connects, since we know the bits are intact. If b) then serving over SSL doesn't obviate the desire to know that someone has attached their identity to the contents, and we should keep the UI intact, or possibly modify it to be clearer on what it's trying to communicate. An obvious reply here is that signing-for-identity assumes that the certs people generally use (self-signed or bargain-basement SSL certs) say anything meaningful about identity anyhow which, by and large, they don't (hence the push in some circles for EV.) Since EV certs are well outside the reach of individual add on developers, this might make the case for a) being the only legitimate way to go. I'm not sure I'm sold, but does anyone want to make that argument?
(In reply to comment #4) > Since EV certs are well outside the reach of individual add on developers, dougt and I pushed to make us completely reject unsigned zippies in Firefox 1.0/1.1, and MS eventually realized accepting unsigned activeX led to a world of hurt. But your comments about EV apply to the availability of code-signing certs in practice given the population of our add-on developers, so we couldn't get any buy-in on it since that would strangle the add-on community. Signing was implemented to do b), but it has to do a) to be able to make the b) claim. This proposed change doesn't make any practical difference. Since we load all of our extensions from insecure mirrors they'd still say "Unsigned". (In reply to comment #3) > people already download plenty of unsigned binary software without > the browser complaining. That's a bug in our browser IMO. IE complains, for instance; we ought to be able to manage it.
(In reply to comment #5) > (In reply to comment #4) > This proposed change doesn't make any practical difference. Since we load > all of our extensions from insecure mirrors they'd still say "Unsigned". Does anything stop those extensions from being signed? Would a signed extension show "Unsigned" if it came from such a mirror?
In comment #3, Justin Dolske wrote: > Encouraging signed extensions would be a good thing, but people already > download plenty of unsigned binary software without the browser complaining. > And install unsigned extensions, for that matter. :-) > We've probably already trained Firefox users that unsigned extensions are > A-OK, and to ignore any dialog that says otherwise. :-( Justin, I'm not sure which of these you're saying: a) when people download and install unsigned binary extensions, we don't warn them that the extensions are unsigned. [actually, I think we do, but the warning SO lacks prominence that if you don't know where to look for it, you might miss it] or b) people download other binaries, such as random .exe files (not extensions), from the net and we don't impose any sort of signature checks on those files, unless they are being installed as extensions.
> This proposed change doesn't make any practical difference. Since we load all > of our extensions from insecure mirrors they'd still say "Unsigned". Extensions on AMO are downloaded using https, or downloaded using http/ftp and checked against a hash that came from https. So it would make a difference for AMO. It would also make a difference for extensions downloaded from my site (https://www.squarefree.com/extensions/).
(In reply to comment #7) > b) people download other binaries, such as random .exe files (not extensions), > from the net and we don't impose any sort of signature checks on those files, > unless they are being installed as extensions. That's what I was saying. I think we should do all we can to make extension installs and update as secure and trustworthy as possible, yadda yadda, but I think as a practical matter that has to be balanced against the ease of which other executable code is made available. We could require an .xpi to be signed by an expensive 3rd party code auditor, but then people would just release .exe installers instead. :-) Or stop writing extensions. :-( I'm wandering off on a hypothetical tangent, though. For this bug, I think the question is how should unsigned extensions be presented to the user (and that's influenced by the how practical it is to require extensions be signed in a meaningful way by authors). Limiting the scope even more, Jesse's comment #2 makes me think an acceptable, minimal change would be to just tweak the existing dialog so it's a little less "scary" looking. That's not significantly changing the status quo, but we can suggest that as a future task on Johnath's to-do list for security UI. [And I just did :-)]
Product: Firefox → Toolkit
I suggest this is wontfix, as code-signing will likely be needed for all add-ons and FF installation files in the future.
(In reply to comment #10) > I suggest this is wontfix, as code-signing will likely be needed for all > add-ons and FF installation files in the future. Do you have anything confirming this statement? I checked the prices of code signing certificates only recently and the costs are prohibitive - unless Mozilla wants to start signing certificates for extension authors, valid for extension installation only. Not to mention the horrible tool chain (you can figure it all out but it takes way longer than necessary).
(In reply to comment #11) > (In reply to comment #10) > > I suggest this is wontfix, as code-signing will likely be needed for all > > add-ons and FF installation files in the future. > > Do you have anything confirming this statement? I'd also be interested to know where this comes from - I haven't heard any mention of this, and I'd like to think I would have.
Btw, I did receive bug reports about the lack of signature, including a review saying something along the lines of "how can this add-on be recommended if its author is not verified". Which prompted me to look for solutions - but proper certificates cost more than I am willing to spend on this while self-signed certificates are pointless. So I would very much like to see this bug solved in one way or another.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > I suggest this is wontfix, as code-signing will likely be needed for all > > > add-ons and FF installation files in the future. > > > > Do you have anything confirming this statement? > > I'd also be interested to know where this comes from - I haven't heard any > mention of this, and I'd like to think I would have. There aren't any specific plans in this direction at this time that I am aware of. It has been discussed in the past but I don't believe we would ever go this route unless code signing became more freely available
In my view, it is likely that within about five years, pretty much all software that people download over the Internet will be signed code, or will be filtered out. Currently, this bug cannot be fixed due to the cost of certificates. Eventually, the cost will probably come down. Maybe some other form of code-signing will become popular. It should not worry us now. I suggest wontfix here because (1) if we fix it, we'll just have to back out the patch later when people start to generally distrust unsigned code, and (2) if the unlikely happens and there is a sudden, unforeseen crisis of hacked code infecting Mozilla extensions, people can be told to only download "signed" extensions. It is proper for Firefox to inform users about an extension being unsigned. That is true information. It is not spreading hysteria. There is no suggestion that they should not install the extension. It is just giving users true information.
(In reply to comment #15) > In my view, it is likely that within about five years, pretty much all software > that people download over the Internet will be signed code, or will be filtered > out. I'm not sure that that will be the case, but if it happens then it happens and we can deal with it then. We shouldn't be closing out bugs because we predict they won't be relevant in 5 years time. > Currently, this bug cannot be fixed due to the cost of certificates. > Eventually, the cost will probably come down. Maybe some other form of > code-signing will become popular. It should not worry us now. Nothing about the cost of certificates means that we cannot fix this bug. In fact it is precisely because of the cost of certificates that this bug exists really. > I suggest wontfix here because (1) if we fix it, we'll just have to back out > the patch later when people start to generally distrust unsigned code, and (2) > if the unlikely happens and there is a sudden, unforeseen crisis of hacked code > infecting Mozilla extensions, people can be told to only download "signed" > extensions. If we reach a point where we decide to only allow the installation of signed extensions then it is likely the UI in question will have to undergo significant changes, possibly even being removed entirely. In either event whether this bug is fixed or not will have little to no impact on the work required there. > It is proper for Firefox to inform users about an extension being unsigned. > That is true information. It is not spreading hysteria. There is no suggestion > that they should not install the extension. It is just giving users true > information. It is important to give users accurate information in a form that they can understand and can then make decisions with. There is valuable information in knowing that an extension was served by a secure webserver and so hasn't been tampered with
Code signatures go well beyond "not tampered with on the last hop". They also protect against "someone phished my AMO password/hacked my dreamhost account/used a bug in AMO to get a hacked XPI in place". The extension is unsigned regardless of how it's transported (should we say it's signed if it came off local disk? no last-hop MITM risk there!) and that signature, if present, ties the software in question to an _author_, not to a domain name.
(In reply to comment #17) > Code signatures go well beyond "not tampered with on the last hop". I agree with this, to a certain extent the fact the installation is from a secure server tells us something different to the fact that the add-on is signed. Possibly I should have pointed out earlier that really what I would expect to see from this bug is simply different UI as opposed to hiding the unsigned UI. I think I'm just going to dupe this to the slightly more general bug 310355 which should be about whether we want to indicate these sorts of things to the user.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.