Updated proposal for ensuring add-on update security

Talk about add-ons and extension development.
User avatar
Mossop
Posts: 717
Joined: January 11th, 2004, 7:24 am
Location: Swansea, UK

Updated proposal for ensuring add-on update security

Post by Mossop »

Hi all, we are currently investigating ways to improve the security of the automatic add-on update mechanism. There are a couple of proposals knocking about and I would like to get some feedback from you if you host your own add-ons and updates (on your own website, not on addons.mozilla.org).

First can you say why you don't host on AMO (doesn't need to be long winded, just want to get an idea of the main issues here).

On the website you host at, do you already use https to deliver the update.rdf and/or the xpi's.

If not what would you think of a plan to only allow automatic updates to extensions that host their update.rdf on a https server (certificates appear to cost from $20 per year), would you be happy to pay that extra money, or move to AMO?

Finally if you still want/need insecure delivery of update files, what would you think of adding an extra step of adding a digital signature to your update.rdf (hopefully just a few commands but still added work nontheless).

There is a bug open on this however I'd ask that you keep your replies here, or to me directly if you prefer then I can collate some overview.

Cheers

Mossop
Last edited by Mossop on July 1st, 2007, 4:46 pm, edited 2 times in total.
old np
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old np »

Someone I've written an extension for hosts the extension on their site because it's sitting in the sandbox on AMO, where people have to log in and read scary warnings to get at it. He has an update.rdf that's not server over https because his site doesn't have https at all.
4711
Posts: 147
Joined: November 5th, 2002, 5:59 am

Re: Proposed changes to the add-on update mechanism

Post by 4711 »

mossop wrote:First can you say why you don't host on AMO (doesn't need to be long winded, just want to get an idea of the main issues here).
Because I don't want to lose the fun in coding.
I simply don't want to complicate my life with "submit-sandbox-review-comment-and-update-terror".

mossop wrote:On the website you host at, do you already use https to deliver the update.rdf and/or the xpi's.

If not what would you think of a plan to only allow automatic updates to extensions that host their update.rdf on a https server (certificates appear to cost from $20 per year), would you be happy to pay that extra money, or move to AMO?
The question goes into the same direction as everything related to Mozilla/Firefox within the last months:
"Do you want to be pseudo-professional?"

mossop wrote:Finally if you still want/need insecure delivery of update files, what would you think of adding an extra step of adding a digital signature to your update.rdf (hopefully just a few commands but still added work nontheless).
Why not? As long as the steps are understandable...
old zeniko
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Re: Proposed changes to the add-on update mechanism

Post by old zeniko »

mossop wrote:First can you say why you don't host on AMO
Mainly because I prefer to schedule my releases myself (so I can react quickly in case of bustage).

mossop wrote:do you already use https to deliver the update.rdf and/or the xpi's.
Unfortunately that's no available option for my main server and not really implemented at mozdev.org, either.

mossop wrote:would you be happy to pay that extra money, or move to AMO?
I'd be happy if AMO allowed to just upload a custom update.rdf "no questions asked". Paying for something I offer for free doesn't really sound attractive...

mossop wrote:what would you think of adding an extra step of adding a digital signature to your update.rdf
How would that prevent MITM attacks? As long as the signature isn't bound to a (paid for) certificate, anybody could claim to be me, couldn't they?
User avatar
Mossop
Posts: 717
Joined: January 11th, 2004, 7:24 am
Location: Swansea, UK

Re: Proposed changes to the add-on update mechanism

Post by Mossop »

zeniko wrote:How would that prevent MITM attacks? As long as the signature isn't bound to a (paid for) certificate, anybody could claim to be me, couldn't they?


No this can actually work. Similar to xpi signing you create a public key and private key. The public key gets distributed in your xpi and you sign the update.rdf with your private key. Then the app can verify the authenticity of the update file against the public key in the add-on.

There's a short discussion on the proposal for how to implement that ongoing on mozilla.dev.tech.crypto.

Thanks for the answers so far guys, keep them coming.
bob4mary
Posts: 59
Joined: March 25th, 2007, 5:45 pm

Re: Proposed changes to the add-on update mechanism

Post by bob4mary »

mossop wrote:First can you say why you don't host on AMO

I do, but I do not want to jump through all the hoops to get my extension public. I think there needs to be some middle ground between public and sandbox. It is especially frustrating when there are a stack of public extensions that have obviously not been updated in ages (do not work on latest software versions).
So I will put the latest versions there but not as my main host.

Perhaps there needs to be a certified category of extensions, this would be a fairly small set that meet very strict criteria not just in quality coding but also need to be things that people actually want (match feature requests, or are downloaded a lot for example). These would be aimed at the average user who just wants things to work. Once an extension makes it to this list it should stay there unless it becomes obsolete, this way people will always know where to find it.

The current public could become easier to get your extension onto, if the developer feels it is ready for public consumption then it goes here. Obviously there needs to be some checks to make sure that the extension is not malicious or dangerous and is described correctly. Extensions in this list should be dumped to the sandbox if they do not work with the current software release or there should be an option to show extensions for previous software releases.

mossop wrote:On the website you host at, do you already use https to deliver the update.rdf and/or the xpi's.

No

mossop wrote:If not what would you think of a plan to only allow automatic updates to extensions that host their update.rdf on a https server (certificates appear to cost from $20 per year), would you be happy to pay that extra money, or move to AMO?

I would not want to pay that myself to give something away. I make donations to charity that help people in real need, $20 to provide my extension or $20 to give people food - easy choice.

mossop wrote:Finally if you still want/need insecure delivery of update files, what would you think of adding an extra step of adding a digital signature to your update.rdf (hopefully just a few commands but still added work nontheless).

If there are clear instructions and it is straight forward, yes.
Provided it does not impact on the development process, there is a way to install an extension without one if you really want to.
old np
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old np »

I don't know if this is within the scope of what you're look for, but regarding the sandbox a bit more... It would be good if extensions in the sandbox could be viewable and installable without requiring a log in. They could still be excluded from the non-sandbox search and listings. I think this would prompt the guy I wrote the extension for to solely use AMO. Currently, getting his site into his user's whitelists is easier than getting them to create an account on AMO.
einare
Posts: 159
Joined: October 22nd, 2006, 1:16 pm
Location: Iceland
Contact:

Post by einare »

I host my extensions at AMO but I think I'm gonna start doing it myself since I don't think this sandbox stuff is working very well. I made 3 extensions before the sandbox stuff started and they all got quite a few downloads and some comments and reviews. I´ve made 3 or 4 more that went in the sandbox, mostly after requests from this place and they have like 3 downloads each, usually the guy that requested them and maybe one or two others. Not that they're real big or important extensions but 3 downloads each? I'm guessing it's because Google doesn't index the sandbox pages so people have no way to stumble upon them. So yeah I´m gonna start hosting them myself and I would definitely not pay extra for https to give something away.

If you keep making the barrier to entry higher (sandbox, https) you'll get more and more people who'll just think "I'ts not worth the hassle" to publish their extensions.
Try my javascript card games, Hearts, Idiot and Crazy Eights
User avatar
Mossop
Posts: 717
Joined: January 11th, 2004, 7:24 am
Location: Swansea, UK

Post by Mossop »

Many thanks to everyone that replied to my questions about add-on updates. I have now put together the beginnings of a proposal for how we will deal with this. It is viewable here: http://wiki.mozilla.org/User:Mossop:Fx- ... teSecurity

I'm sure there will be some points in there that some of you will want to discuss, I think that here is a better place for discussion rather than on the wiki. If you do feel the need to put small comments on the wiki then please do so on the discussion page for the article, don't edit the main page directly.

Cheers

Mossop
bob4mary
Posts: 59
Joined: March 25th, 2007, 5:45 pm

Post by bob4mary »

It does not look like you have taken anything that anyone has said here into consideration. Maybe you could go back through some of the posts and tie in what people have said to specific parts of your proposal, so at least people feel they have been listened to.

Feel free to improve security, but you need to let people get their extensions out there.

I also did not notice how the proposed changes would impact on the development process, I assume that I will still be able to make my own extensions, for my own use without having to do anything that is in the proposal?
User avatar
netMASA
Posts: 617
Joined: July 26th, 2006, 3:21 pm
Location: On the internet
Contact:

Post by netMASA »

Are we doing this because of the wannabe security "expert" who "found" a hole and made people's extensions look bad without first contacting them and telling them of the exploit so they could have made changes before he made the notice public?

I am not happy with that guy at all. Personally, I think he is just trying to make his name known.
User avatar
Mossop
Posts: 717
Joined: January 11th, 2004, 7:24 am
Location: Swansea, UK

Post by Mossop »

bob4mary wrote:It does not look like you have taken anything that anyone has said here into consideration. Maybe you could go back through some of the posts and tie in what people have said to specific parts of your proposal, so at least people feel they have been listened to.


Is there anything in particular you are concerned about? The biggest issue raised both here and on the newsgroups was that requiring SSL was costly and difficult for authors. So we have decided to go the extra step and not require SSL for updates. The idea of allowing authors to upload their own update.rdf to AMO is unfortunately not really workable[/quote]

bob4mary wrote:I also did not notice how the proposed changes would impact on the development process, I assume that I will still be able to make my own extensions, for my own use without having to do anything that is in the proposal?


So long as you don't specify and updateURL in the extension's install.rdf then it will install since Firefox will presume you are using AMO for updates which is a secure URL. So during testing you need take no extra steps to make this work, it is only when yu come to want to release your extension and have it update from your own site that you would have to take any extra steps.

netMASA wrote:Are we doing this because of the wannabe security "expert" who "found" a hole and made people's extensions look bad without first contacting them and telling them of the exploit so they could have made changes before he made the notice public?


A public disclosure of the vulnerability has sped up activity on this yes, but it's not solely from that. However regardless of who found the hole, users are potentially at risk.
User avatar
netMASA
Posts: 617
Joined: July 26th, 2006, 3:21 pm
Location: On the internet
Contact:

Post by netMASA »

Ugh, I hate that guy. He could have told me first before making my extension look bad. I want to slap him soooooooo hard.
Check out ThunderBrowse, the browser for Thunderbird. Donate to ThunderBrowse!
ericjung
Posts: 846
Joined: August 4th, 2003, 9:32 am

Post by ericjung »

Mossop has fragmented this discussion into numerous sources: this forum, two or three newsgroup threads, bugzilla, his wiki, and possibly other sources of which I'm not aware.

In case anyone wants to see complaints/concerns at the other sources, here they are.

Newsgroup discussions:
http://groups.google.com/group/mozilla. ... 1888d8708c

Wiki proposal:
http://wiki.mozilla.org/User:Mossop:Fx- ... teSecurity

Forum discussion:
http://forums.mozillazine.org/viewtopic.php?p=2927908

Bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=378216

There's also at least one discussion in the dev.crypto newsgroup.
Last edited by ericjung on July 3rd, 2007, 12:00 pm, edited 1 time in total.
sdwilsh
Posts: 563
Joined: November 6th, 2005, 9:46 pm
Location: California

Post by sdwilsh »

ericjung wrote:In case anyone wants to see complaints/concerns at the other sources, here they are. It would seem as if Mossop has the power to push this into the codebase regardless of what might be best for the community (i.e., lowering -- not raising -- barriers to entry).


Or, you know, maybe he's just trying to get the word out to as many people as possible? Not everyone reads the forums, and not everyone reads the newsgroups.

And the wiki page, well the text right across the top (and the url - it's his talk page) seems to indicate that it is more or less used to keep track of the the information for himself...
Please don't edit this page directly, either add comments to the discussion page or to the threads in the <a href="http://groups.google.com/group/mozilla.dev.extensions/browse_frm/thread/a29f213e165d8267/93a7917b0c1e63c3">newsgroup</a> or <a href="http://forums.mozillazine.org/viewtopic.php?p=2927908">forums</a>. See also the original newsgroup thread where extension authors discuss the potential impact to the addon community.
Locked