<div dir="ltr">On Tue, Aug 18, 2015 at 5:41 AM, Richard Z <span dir="ltr"><<a href="mailto:rz@linux-m68k.org" target="_blank">rz@linux-m68k.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 17, 2015 at 08:10:32PM -0700, Dave Townsend wrote:<br>
> On Mon, Aug 17, 2015 at 7:38 PM, Matthew Turnbull <<a href="mailto:sparky@bluefang-logic.com">sparky@bluefang-logic.com</a><br>
> > wrote:<br>
><br>
> > Perhaps a compromise is to have a dual authentication system:<br>
> ><br>
> > * Support signed extensions as-is.<br>
> > * Support unsigned extensions using the master password and a key-pair for<br>
> > signing.<br>
> ><br>
> > In the unsigned extension case, generate a local extension signature and<br>
> > store it in a local database. Sign that database using a generated<br>
> > key-pair. This way, the database can be read by everyone (i.e. without<br>
> > prompting for the password) and it can only be updated after unlocking the<br>
> > private key with the master password.<br>
> ><br>
> > To get around the case where malware could replace the database and public<br>
> > key, have the key-pair issued by a remote Mozilla service so that the<br>
> > public key can be validated as authentic. If an invalid public key is<br>
> > found, invalidate the database and disable the now unsigned extensions<br>
> > until the user manually re-enables them. If the public key was also stored<br>
> > behind the master password, then it could be restored without issuing a new<br>
> > pair.<br>
> ><br>
><br>
> This is a complex system to support what should be a small number of users<br>
> as we expect most legitimate add-ons to be signed. If users need to use<br>
> add-ons that don't fall into that set then they can use the unbranded<br>
> builds which are identical to Firefox releases in every way except that<br>
> they have different icons and naming and can be configured to allow<br>
> unsigned add-ons.<br>
<br>
</div></div>complex but not rocket science. There are in fact more scenarios where Firefox<br>
should rely on private/public key signing and verification - for example the<br>
downloads/updates of binary plugins which are currently secured only using SSL<br>
cert pinning as far as I can see.<br>
<br>
How safe is the extension signing process anyway? When there is a fast-track<br>
method to sign unlisted extensions within seconds without manual review it is<br>
quite foreseeable malware distributors will try everything to abuse this method.<br>
If they succeed it might make things even worse because users would get<br>
"officially signed" plugins and be even less cautious.<br>
Securing against this might in turn make the whole fast-track signing process<br>
inconvenient for legitimate users.<br>
<br>
So either automatic reviews are sufficiently secure for all purposes or the<br>
whole process may be busted.<br>
<br>
As long as users are willing to donwload plugins or software from many<br>
places I am not sure this is going to save the world.<br><br></blockquote><div><br></div><div>Not the world no, but we hope to make a significant impact on the amount of rogue add-ons users have. Yes it's true the automatic validator could in the future be shown to have bugs and it could be possible for an add-on to slip through one of those bugs with something nasty in it. The same goes for the manual reviews, no automated or manual system is perfect. But at that point we can revoke that add-on's certificate and users will never be able to sign or use it again.<br><br></div><div>Compare this with the current situation where there is no verification of add-ons at all unless hosted at AMO. Someone can inject a rogue add-on into Firefox and our only option is to blocklist it but the blocklist system relies on the add-on remaining the same and malware will distribute an add-on in thousands of variations with unique IDs and other changes making it impossible for us to blocklist them. <br></div></div><br></div></div>