I must point something out here. You could just as easily have a 'trusted source' by allowing the plug-in author add their own 'updates to this plugin will come signed by *this* key' certificates to the other certificates' keystore.
This would minimize all of the problems of mozilla.org being attacked, due to the digital signatures present on the packages. If mozilla.org chooses to publish revocation certificates, even in the event that mozilla.org is attacked, the only potential damage is from removal of information rather than addition or changing of information. This is because the revocation certificates are already signed by the key that they belong to. Putting more of the power into the hands of the users (and minimizing the ways that they can be pwned, and minimizing the possible risks of services that mozilla.org has available for the public, seems like a good thing. -Kyle H On 6/25/07, Gervase Markham <[EMAIL PROTECTED]> wrote: > Nelson B wrote: > > Unless the page that contains that link is an https page, to substitute a > > trojan, an attacker need only substitute his own URL for the original > > page's URL while the page is in transit. A proxy server is a perfect > > place to perform such an MITM attack. Http pages with login forms that > > submit their contents via https have the very same vulnerability. > > You are correct. > > Link Fingerprints is a way to validate a download from an untrusted > source, when you start with a reference from a trusted source. If the > orginal source is not trusted, then the system does not provide complete > protection. > > It still provides some protection, because hacking the download box and > then doing an MITM on the downloader is harder than just hacking the > download box alone. Note that also, for the alarm not to be raised, you > would need to MITM _every_ downloader. > > However, I will make it more clear in the spec that the original URL has > to be provided from a trusted source. > > Gerv > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
