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

Michael Vincent van Rantwijk, MultiZilla mv_van_rantwijk at yahoo.com
Wed Jul 18 10:11:17 PDT 2007

Douglas E. Warner wrote:
Douglas E. Warner wrote:
> On Wednesday 18 July 2007, Michael Vincent van Rantwijk, MultiZilla wrote:
>> But talk is that MoCo wants SSL protected downloads in the (near)
>> future, but couldn't get it going for MF3 because of various reasons,
>> and the same reason why this add-on signing of extensions was taken into
>> account.
> If you have links to documentation or discussion that says this, please share 
> it. 

I can't.

> So far the only discussion that we've been part of has been the updates 
> process for Firefox 3, 

Why not link finger printing?  I know, keep repeating myself... but 
because this is an important feature to have when you just sign your XPI's.

> and the solution we've chosen to support for 
> Mozdev.org is valid by the current proposal.  SSL does not buy us anything.

Yeah, because you refuse to look any further than XPI files, but JAR 
files served off from mozdev.org are still vulnerable.

>>    Myk said to have troubles when people start using the mozdev.org
>> certificate for other thingsIs this "no go" just a technical, or a
>> political decision of mozdev.org? , like updates.rdf for examples, is
>> this perhaps the reason, or what else is it that you guys are so
>> reluctant to implement this?
> SSL is very difficult for us to implement for several reasons; some are 
> technical, some are financial, some are legal.
> 1) Our mirrors don't support SSL.  

Currently not, no.

> We can't force them to support SSL.  

Well, have you asked them?

> If we 
> did force them to support SSL, it would probably be our responsibility to pay 
> for the certs and additional server resources needed to serve SSL-encrypted 
> files.

Are you saying that mozdev.org covers their data transfer right now? If 
not, don't you think they can handle the extra 28 dollar?

> 2) Wildcard certs for *.mozdev.org are expensive.

So don't use one.  You don't necessarily need one, and I thought this 
was clear by now already.  Just point to:

https://www.mozdev.org/install/projectname/ (or whatever) and you're done.

Let's talk business: What is the exact price of such certificate, in 
case you still want it?  Would you mind setting up a project owners 
donation pool for it?

> 3) We're not sure of the legal repercussions of getting a *.mozdev.org cert.  
> Mozdev doesn't do the verification of a project owner that a Certificate 
> Authority would do for an individual SSL certificate.  If we were to get a 
> malicious project that was able to "securely" install by using our 
> certificate, who would be responsible?

What is the difference?  If anyone installs a malicious program from 
mozdev.org you're toast already... with or without any certificate!

You want the door to stay open and wait for bad things to happen, 
because only this 15 years old kid is smart enough to understand what is 
going on?

>> "If you are serious about security and your extension/add-on, then you
>> would get a code signing cert.
>> The best protection we have right now for extension security is to sign
>> them. "
>> ...and a host that supports SSL, or be prepared to get bitten one day
>> soon ;)
> SSL is not the "end all", especially since it only proves that the package 
> came from Mozdev.org, not that it should be trusted.

Exactly! Now scroll up now and read point 3 ;)

FYI: Liability is already a huge issue, because you didn't bother to 
protect your customers, and because all visitors belong to mozdev.org 
so... why wait for trouble?  Go get some help from your lawyers, who I'm 
sure will send you a nice bill... worth spending a certificate maybe?

> I'm sure there are other solutions available - unfortunately there aren't 
> supported or being developed by Mozilla at the current time.  The other 
> solutions just aren't technically and financially (and possibly legally) 
> feasible for Mozdev right now.

Hell yes, they have link finger printing *and* SSL, which in combination 
helps a great deal.  Why do you think that was developed?  Why do you 
think they use it?  For the kick of it?

p.s. May I ask who your previous employer was?

Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member
- iPhone Application Developer

More information about the Project_owners mailing list