From 0968f903fe66f9bb8957b8d01e35f3743c74404b Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Tue, 4 Nov 2014 11:31:31 +0100 Subject: Brought old blog over --- ...ing-certificate-authorities-with-convergence.md | 88 ++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 content/technical/ditching-certificate-authorities-with-convergence.md (limited to 'content/technical/ditching-certificate-authorities-with-convergence.md') diff --git a/content/technical/ditching-certificate-authorities-with-convergence.md b/content/technical/ditching-certificate-authorities-with-convergence.md new file mode 100644 index 0000000..69c8ce8 --- /dev/null +++ b/content/technical/ditching-certificate-authorities-with-convergence.md @@ -0,0 +1,88 @@ +Title: Ditching Certificate Authorities with Convergence +Date: 2011-09-06 19:49 +Tags: security, gnome +Slug: listened-to-moxies-talk-about-trust + +Listened to [Moxie's][] [talk about Trust Agility and 'Convergence'][]. +Sounds like a viable candidate for ditching the Certificate Authority +mess, or at least part of a solution. Go [watch the video][talk about +Trust Agility and 'Convergence'] if you haven't already. + +I was thinking about how we could implement support for +[Convergence][] in GNOME. The local cache of discovered valid +certificates would work far better across an entire desktop, rather than +each application (browser or otherwise) including code, configuration, +and storage to do it on their own. + +In fact it fits in nicely with the Trust Assertion stuff I've been +playing with. It'd be relatively straightforward to build a [PKCS#11 Trust Assertion module][] which used Convergence to seed Trust +Assertions. That would plug in easily to [GLib][], [GCR][], NSS etc. +(modulo a few patches not yet merged). + +But a few things popped into my mind while watching the video. Stuff +that it seems would need to be solved before this can be implemented as +general purpose solution. This is just off the top of my head, and +perhaps I'm woefully mistaken about something: + + +1. **Protocols and Options:** Since I work for Collabora and we have a + thing for XMPP, the first thing that stood out to me, is that the + protocol is limited to HTTP, and more specifically SSL. Nearly every + other protocol uses TLS for security. + + So for starters this means that when the Notary wants to retrieve + the certificate it'll need to know how to speak a given protocol. I + guess different notaries could know speak different protocols when + fetching the certificate from the target server? + + Then the Convergence protocol would need to be changed to allow the + caller to specify a well known protocol. Perhaps the protocol would + also need some sort of capabilities support so that clients can know + which Notaries can do what? + +2. **TLS Options, Extensions:** Taking this a step further, the Notary + would need to provide the same TLS options and extensions that are + used in the handshake. Most obviously: [SNI][] + +3. **Hash Algorithm:** The protocol currently hardcodes things like + SHA-1, which isn't aging very well. And as we've learned, [it's often better to pass the entire certificate around][]. Or at least, + have it extensible where you can specify a hash algorithm to use. + +4. Obviously Convergence doesn't (and probably can't) work if the + server is requiring client certificates. I guess it's not meant to + solve this use case though. + +5. The installing of Notaries by downloading them as files from + websites (including the certificate) smells sort of wrong, at first + whiff. But if you figure that several Notaries would be distributed + with a distribution (and could later be updated as necessary) and + the certificates of websites hosting additional .notary files could + be checked using the initial set of Notaries, then I guess it sort + of makes sense. + +6. **Protocol Specification:** Last but not least, the protocol needs to + be documented and reviewed. + +About usability: Obviously most users will never care about checking +which Notaries they use. I have a hard time expecting most people to +care. But they don't have to. + +The Trust Agility comes with the fact that a distributor like GNOME +could easily ship a default set of Notaries, and then update them as +needed without affecting functionality. As Moxie points out the browser +vendors can't even disable [screwballs like Comodo][] because it would +disable a quarter of the web. So that's where this is different. You can +replace screwed up Notaries without affecting functionality. + +And no more self-signed certificate warnings. Seriously, that dialog +(wherever it's implemented) is the worst security cop-out ever. + + [Moxie's]: http://thoughtcrime.org/about.html + [talk about Trust Agility and 'Convergence']: http://www.youtube.com/watch?v=Z7Wl2FW2TcA + [Convergence]: http://convergence.io/ + [PKCS#11 Trust Assertion module]: http://p11-glue.freedesktop.org/trust-assertions.html + [GLib]: https://bugzilla.gnome.org/show_bug.cgi?id=656361 + [GCR]: http://developer.gnome.org/gcr/unstable/gcr-Trust-Storage-and-Lookups.html + [SNI]: http://en.wikipedia.org/wiki/Server_Name_Indication + [it's often better to pass the entire certificate around]: http://p11-glue.freedesktop.org/doc/pkcs11-trust-assertions/#justification-why-no-hash + [screwballs like Comodo]: http://www.livehacking.com/2011/03/31/comodo-saga-continues-two-more/ -- cgit v1.2.3