Today, Moxie Marlinspike, a security researcher famous for his research on Android and SSL and related protocols (author of sslstrip/sslsniff), released "Convergence" which says is "an agile authenticity replacement for SSL" and attempts to address the problems the that are created by the idea of trusted Certificate Authorities.

The website that features a firefox plugin (client code) and a notary (server code) is here: http://convergence.io/

It is also open-source on github.

What are the pro's and con's of Convergence as an SSL replacement?


3 Answers 3


Just to be clear, it's explicitly not an SSL replacement. It's a replacement for CAs, with the explicit design goal of not forcing some giant IPv6-like "change the world" rollout. It's based in large part on earlier work on solving the SSH Host Key validation problem - see http://www.usenix.org/event/usenix08/tech/full_papers/wendlandt/wendlandt_html/

In Convergence, there are some number of network topologically distant "Notary" services, run by a diverse collection of different organizations. The (self-signed) SSL certs for each of the Notary endpoints are baked into the browser. When the browser hits an https site for the first time, it fetches the cert and then dials out to all N of its Notaries, and says "I went to talk to www.example.com:443 and got back this SSL cert. Is it good?". The Notaries issues a yay or nay. If all the Notaries say "yay", the browser caches the cert up to the cert's natural expiration date. On subsequent requests to www.example.com:443, the browser compares its cache against the cert it just received. If there's a mismatch, it dials back out to the Notaries again. Since sites don't do cert rotation that often, and browsers can do super-aggressive cert caching (and key-rotated certs get cleanly invalidated from the cache), it's not an inherently un-scalable solution.

The Notaries are free to set whatever policy they want for what constitutes a good or bad cert. The suggested ones are "Notary's servers poll site", "Notary consults the EFF SSL Certificate Observatory", "Notary checks for what cert is on file in DNSSEC", or even "Notary does traditional CA validation".

I think it's the most unintrusive solution to the CA problem ever. Aside from convincing MS/Apple/Google/Mozilla to jump on it (and the Citibank problem), there were two issues that bugged me.

First one is captive portals (e.g., airport or hotel wifi). He handwaved past that a bit, and proposed using DNS as a fallback protocol to communicate with the Notaries. But, there are numerous captive portals that'll just eat DNS records other than A & CNAME.

Second one is what's the financial incentive to run a Notary? To scale, there are going to have to be tons of these things. Some orgs might run them out of the kindness of their hearts, much as DNS roots are done, but I think the architecture of DNS scales quite a bit better than Convergence.

  • 1
    The purpose of SSL CAs is to have an authoritative signature chain for a key and authenticate that to the domain. Signing DNS requests and putting the keys there for query removes the issues of having to trust a 3rd party though another mechanism. If your DNS query is properly signed, then you know the key matches the domain and that's that. I think he's replacing one complexity with another here.
    – Jeff Ferland
    Aug 5, 2011 at 14:41
  • 2
    Actually, this is proposed as a deliberate alternative to putting SSL certs in DNS. In DNSSEC, you're replacing one set of trusted parties you have to trust forever (the CA's) with another (the registrars and TLD administrators). And again, you can never stop trusting them. With Convergence, as long as there are other Notaries out there, you're free to ditch any Notary as soon as it starts exhibiting sketchy behaviour.
    – LValue
    Aug 5, 2011 at 19:10
  • 1
    I just sat through his talk and have ben convinced that it has a very valid need even if it does keep some of the complexity that I don't like. e.g. If I want to securely communicate with google.cn, I don't trust China with the key even if the DNS resolution is their job.
    – Jeff Ferland
    Aug 5, 2011 at 20:56
  • 1
    Actually, the aggressive caching of certs this way is very bad. If a cert is compromised, then no browser will check for revocation information until the cert is expired, which is worse than today's model. Also, random connections to random servers for the Notary can be blocked inside an organization, so you fail to connect.
    – Nasko
    Aug 10, 2011 at 16:16
  • I'd point out that Moxie Marlinspike is a friend of Dan Kaminsky (of DNSSEC fame), and they have had several conversations on twitter about the limitations of DNSSEC.
    – ewanm89
    Sep 2, 2011 at 18:58

Regarding PKI through DNSSEC, Moxie touched on why that's even worse that the central trust of CAs. There is a little more on that available here: http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity

Another poster asked about the financial incentive to run a notary. Consider all of the signed SSL certs purchased every year. Some organizations spend thousands on SSL certs. If each of those organizations ran a notary your financial incentive problem would be solved simply by not having to pay SSL signing fees.

I don't have an answer for captive portals... those are just annoying to begin with.

  • Here is the part of the video where Moxie Marlinspike talks about the weakeness of DNSSEC (like CAs): centralized trust (goo.gl/PDyoJ). With Convergence you can decide who you trust and you can revoke a notary at any time without breaking the SSL scheme alltogether. The other great point is that it works, now. (That doesn't mean DNSSEC is a bad thing, it's just that Convergence aims at the root problem instead of one of its leaves, the two can collaborate easily through "DNNSEC notaries")
    – Shadok
    Sep 9, 2011 at 20:34
  • For completeness here are the part where he talks about Convergence's weaknesses: goo.gl/BWUfb
    – Shadok
    Sep 9, 2011 at 20:46

This is made obsolete by hopefully soon-to-be-deployed PKIs based on DNSSEC. Then you get your cert from DNS, signed by the DNS authority which in turn can be linked to the root servers. Maybe we'll finally get a free P'n'P PKI with that. Since DNSSEC is not using X509, this would also be the chance to get rid of it. Just add SPKI key types to TLS and slowly migrate away.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .