canmove, Confirmed users
1,570
edits
Extension Manager:Addon Update Security: Difference between revisions
Extension Manager:Addon Update Security (view source)
Revision as of 18:24, 28 June 2007
, 28 June 2007→Proposed Implementation
| Line 18: | Line 18: | ||
== New Requirements == | == New Requirements == | ||
== Proposed Implementation == | == Proposed Implementation == | ||
In order to make the automatic update of add-ons secure there are two main steps to be taken: | |||
* Ensure that the update manifest is retrieved in a secure fashion | |||
* Ensure that the update package retrieved matches that specified by the update manifest. | |||
The following details how we meet those steps. | |||
=== Requiring Update Hashes === | |||
The update manifest currently contains an optional property, the updateHash. This will become an absolute requirement for updates. Any updates listed in the update manifest missing a hash will be ignored. | |||
* Do we need to restrict the hashes available? Currently we allow md2, md5, sha1, sha256, sha384 and sha512. Presumably finding a collision that still makes a valid add-on in an xpi file will be quite a challenge. | |||
This provides a high level of confidence that the update package that will be downloaded is the same update package referenced from the update manifest regardless of the security of the connection used to retrieve the package. | |||
=== Securing Updates Through SSL === | === Securing Updates Through SSL === | ||
Add-ons may choose to host their update manifest on a secure site backed by a valid SSL certificate. This is likely to be the easiest case from a developers point of view and probably the only method suitable for automatically generated update manifests such as those being built from a database. | |||
This mechanism ensures that the update manifest has been retrieved un-tampered from the url specified by the add-on. It should be noted though that this does not guarantee the update manifest came from the original add-on author since the domain name hosting the manifest may have changed hands. | |||
=== Securing Updates Through Digital Signatures === | === Securing Updates Through Digital Signatures === | ||
=== Non-conforming Add-ons === | |||
Add-ons that do not provide either of the previous methods of retrieving a secure update manifest must not mark themselves as compatible with Firefox 3. During install a check will be performed to ensure that it meets the requirements and Firefox will refuse to install any add-ons that do not. | |||
* Do we really want to block install and not just update? | |||
* What do we do if we spot that an installed add-on is suddenly using an insecure update method? | |||
=== Migration === | === Migration === | ||
In order to support updating add-ons which do not currently meet the new requirements there will be the possibility of a single insecure update check for the add-on when the user first updates to Firefox 3. | |||
In this case a standard insecure update check can be performed. If the check finds an update marked compatible with Firefox 3 then the user may opt to install it. The update package will then undergo the same checks as during a regular install in Firefox 3 and assuming it succeeds (which is should if it is marked as compatible with Firefox 3) then the add-on will be updated and receive secure automatic updates thereafter. | |||
== Impact to Add-on Authors == | == Impact to Add-on Authors == | ||
=== Authors Currently Hosting at AMO === | === Authors Currently Hosting at AMO === | ||