[Project_owners] XPI install still vulnerable to MITM attacks on mozdev.org

Douglas E. Warner silfreed at silfreed.net
Wed Jul 18 05:30:02 PDT 2007

On Wednesday 18 July 2007, Michael Vincent van Rantwijk, MultiZilla wrote:
> XPI installations initiated from mozdev.org will still be vulnerable to
> MITM attacks... when the XPI isn't *installed* originally from a SSL
> protected server!
> a.m.o is secure, so in that case you can get away with simply signing
> your updates, but each new installation will still be vulnerable to MITM
> attacks, and this will be the next step in this process... to prevent
> you from installing XPI's from insecure http: connections.
> Why is this so hard to understand?

AMO does not provide SSL downloads for it's releases either - it's in the 
exact same boat as Mozdev.org is.

(Try for yourself - Addons hosted by AMO are served from 
http://releases.mozilla.org/pub/mozilla.org/addons/; you won't be able to use 
the HTTPS version).

This is simply a logistical problem due to both organizations relying on 
public mirrors for distributing its bandwidth.  We can't reasonably expect 
these mirrors to support the additional cost of an SSL cert or CPU overhead 
of running SSL.

We do understand that the initial process of installing an XPI is susceptable 
to a MITM attack, but so far this part has been deemed less important by 
Mozilla since it is a user-initiated action and they are prompted for it to 
continue, whereas the automatic updates process was not user initiated 
therefor could be more easily intercepted.

The exploit you listed was specifically for the update process because it is 
much easier to predict - a user installing some random extension is not very 
easy to exploit since it's much harder to predict.

Since the updates.rdf file is signed by the same key installed with the XPI 
originally and the XPIs referenced in the updates.rdf file have hashes of the 
files stored in the updateHash element, the updates process will be safe from 
MITM attacks.  This has been Mozilla's (not Mozdev's) primary concern for 
Firefox 3 - and the one most easily supported without requiring developers 
get code-signing certs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mozdev.org/pipermail/project_owners/attachments/20070718/208b13ed/attachment.bin 

More information about the Project_owners mailing list