Gervase Markham schrieb: > Dave Townsend wrote: >> What I want is to be able to be able to establish some trust that the >> update file retrieved is correct, and has not been tampered with, >> intercepted and is as it was originally written by the add-on author. > > Link Fingerprints was designed for precisely this purpose, and is > currently being implemented in Firefox by Ed Lee, who is sitting next to > Dan Veditz: > http://www.gerv.net/security/link-fingerprints/ > > You get the URL from a trusted source (i.e. the updates.rdf downloaded > from addons.mozilla.org over SSL) and then use the fingerprint to verify > that the data you get is actually the correct data. You can download it > over HTTP, from an "untrusted" site, because if you get the wrong data, > the implementation throws it away and tells you so. > > No changes would be required to the updates system (apart from update > authors having to specify the fingerprint when they register a new > update) and they can use any web host they like - cheap, free, whatever. > It's much easier to manage than certificates and I believe, for this > application, gives equivalent security. > > Gerv
Err, I actually started wondering when you'll get here advertising your solution... AMO already uses link-fingerprint like hash verification... Link-Fingerprints cannot solve the problem of update.rdf-over-HTTP as update.rdf is likely to update often and you cannot compute hash(es) for it in advance. So even if update.rdf included LF for the update XPI it wouldn't matter, as update.rdf itself can be intercepted and the LF could be replaced or removed. If you're proposing that all extensions or at least their update.rdf must be served via AMO, then no thanks. Link-Fingerprints in general fail the requirements that Dave defined: > What I want is to be able to be able to establish some trust that the update > file retrieved is correct, and has not been tampered with, intercepted and is > as it was originally written by the add-on author. * correct? OK, possible at least in some scenarios. * tampered with/intercepted? It cannot be ensured that somebody tampered with update.rdf. * written by the add-on author? No way for LF to solve this. Nils PS: the Link-Fingerprints "standard" says: > Clients are encouraged not to implement any hash algorithms other than MD5 > and SHA-256, until and unless SHA-256 is found to have flaws. MD5 is broken, you can find collisions in just hours. Therefore having authors providing md5 hashes doesn't really help either. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
