Zooko Wilcox-O'Hearn wrote:
began with him mentioning a specific use case that he cares about and sees how to improve: authentication of Mozilla plugins.
From what I can tell, the Sparkle update framework (for OS-X)[1] is doing something like what I want for firefox: the Sparkle-enabled application will only accept update bundles which are signed by a DSA
To be specific, the itch that I was looking to scratch was the authentication of Firefox updates. In some slides from the last BlackHat, I was dismayed to learn that the firefox update process depends utterly upon SSL and the assorted Certificate Authorities to validate https URLs that land on a mozilla.org server. The actual update bundles that are fetched from those https URLs are not validated at all. This causes two problems. The first is that any failure of the SSL or CA path will allow an attacker to subvert the update process and take over the browser. The slides I looked through showed one easy attack (the ASN.1 pascal-vs-C-string bug) which has since been fixed. But we've seen lots of failures at this level, and there are dozens of CAs in the TCB: a compromise of any one of them would break everything (some are still using MD5). Since firefox checks in daily to find out about new updates, there are lots of opportunities to mount this attack. The second is that it limits Mozilla's mirroring possibilities. I think that they currently have to hand out private keys to their mirrors, something like a cert that designates the server as mirror1.mozilla.org, so they must be very cautious about who runs each mirror. Their mirrors must all be running SSL, and a compromise of any of those mirrors could jeopardize the whole update path. I think that they could have far more mirrors (and be better able to accomodate the tens of millions of firefox users) if they didn't have this limitation. Having an end-to-end method to validate the update bundles would fix both of these problems. Updates could even be acquired via other means (sneakernet, local mirror, etc) and validated by the browser individually before unpacking+installation. Plugins could conceivably used something similar, but I think the basic browser update path is a valuable one that's easier to reason about. privkey that matches a pubkey embedded in the app. It'd be nice if Firefox could do the same. And if Firefox were to establish a quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong URL-based authentication of HTTP resources, then other applications could start using it too, and a significant class of current web security problems (like the mixed-content one where an HTTPS page loads a javascript library via HTTP) could be fixed. cheers, -Brian [1]: http://sparkle.andymatuschak.org/documentation/pmwiki.php/Documentation/Basi... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE