Convergence: User-controlled SSL certificate checking

SSL certificate authorities (CAs) have been in the news quite a bit in the past year or so, and not in a good light. Back in 2008, researchers at Carnegie-Mellon University published a paper outlining a different approach that they termed Perspectives, in which a user would query multiple independent "notaries" about the authenticity of an SSL certificate, rather than relying on a centralized CA. Convergence is a new project that builds on the ideas established in the Perspectives system, ideally to increase privacy, flexibility, and speed. Its creator argues that it can completely replace the CA system solely with browser-side adoption — although not everyone agrees.

Why anyone cares (or should...)

To review, the CA system is designed to foil a particular type of attack on SSL connections: the man-in-the-middle (MITM) attack, in which an attacker intercepts a browser connection destined for a secure site, makes its own connection to the secure site instead, and rewrites all traffic between the browser and the site — copying down the secrets it wants to steal, but otherwise invisibly maintaining the connection between the two endpoints. From both endpoints' point-of-view, the traffic would be encrypted.

Using the CA system, however, the browser first asks the server for its identity in the form of a certificate, and checks that the certificate is cryptographically signed by a trustworthy external authority, the CA. "Intermediate"-level CAs have their own certificates signed by parent CAs, eventually chaining all the way back to one of a select group of root CAs whose certificates are installed with the browser.

The trouble is that the entire framework hinges on those root CAs being impenetrable, which the recent Comodo and DigiNotar attacks prove is, sadly, not true. Attackers can break into a CA and use its secret key to sign rogue certificates of their own invention. There is also the possibility of CAs (or their employees) being subverted by criminals or governments to create rogue certificates. The signature on a rogue certificate checks out as authentic, hijacking the entire chain of trust.

Perspectives

Perspectives (and the Firefox extension that implemented it) was actually created to solve a slightly different problem: how to verify the identity of a self-signed certificate, which by its very nature cannot be checked against a "trusted" third-party CA. Instead, Perspectives relies on the collective judgment of a set of "notaries" — independent servers that request certificates from sites.

The browser queries multiple notaries about a particular certificate, and each one reports back a fingerprint of the certificate it gets from the site. If the notaries are on different routes to the server in question, and all see the same certificate, then the certificate is probably legitimate. The other possibility is that an attacker has taken over the routes between all of the notaries and the chosen server and is performing a MITM attack on each of them — in which case, the browser is simply up SSL Creek without a paddle. That type of false-positive is unlikely, however, and an attacker powerful to perform it (a national network backbone provider or government, perhaps) would be difficult to escape.

The Perspectives technique provides a way to check a self-signed certificate's authenticity courtesy of what the original paper calls "multi-path probing", but it has the nice property of providing similar authenticity assurances for CA-signed certificates, too. The implementation in the Firefox extension had its problems, however — it only performed notary verification for the initial HTTPS request, not subsequent elements like images and scripts, and there was a noticeable lag time between querying a notary and getting a response in return (which may in part be due to the notary re-requesting the certificate before responding). On top of that, it has simply not been regularly updated to work with ongoing Firefox builds, which periodically makes it unavailable for frequent updaters.

Convergence

At Black Hat 2011 in August, developer Moxie Marlinspike presented an extended version of the Perspectives technique he called Convergence. Convergence tackles both of the aforementioned issues directly, decreasing lag time through caching (although there does not appear to be any hard data comparing the speed of the two approaches), and checking all HTTPS requests through the notary mechanism. But it pushes the envelope in other ways as well.

First, although it could serve as a double-check mechanism for CA-verified certificates, Perspectives did not bypass Firefox's built-in CA verification system; Convergence replaces it entirely. This can even be seen in the UI: Firefox's standard "identity block" to the left of the location bar shows the name of the site and the CA used to verify its SSL certificate, while the Convergence extension replaces this information with "verified by Convergence" instead.

Marlinspike was also concerned about the privacy implications of Perspectives: notaries were in a position to track browser behavior by collecting the IP address (and other connection information) of each request and logging the SSL certificates it queried. Convergence attempts to guard against this by enabling each notary to serve in two distinct modes, either making SSL certificate queries, or acting as a relay (a function which Marlinspike calls a "bounce node").

In this scheme, when the browser needs to check a certificate, it first chooses a bounce node. Subsequently, the browser sends certificate queries to the bounce node, each destined for another notary and encrypted with the public key contained in that notary's ID "bundle", which is a publicly-accessible .notary file on the notary server. Which notary it chooses does not affect the protocol; it could be randomized for each query or the browser could select a personal favorite. The bounce node forwards the query to the notary (who decrypts and executes it), and forwards the notary's response back to the browser. Thus the bounce node knows who sent the query, but cannot read it, and the notary used knows what certificate is requested but not who asked, ultimately preserving the browser's anonymity. Using more than one notary is critical to both the Perspectives and Convergence approaches, but how many notaries are used in order to deem a certificate "verified" is left up to the user

The Convergence Firefox extension is available directly from the project web site, although, disconcertingly (and ironically, for a security project), it asks to install itself directly rather than offering a download link — or even a means to check the signature on the transmitted .xpi file. The extension source code is also available on Marlinspike's GitHub site, as is the notary server code. The server code is written in Python, uses SQLite, and requires only generating a key pair and an empty database to begin. Each notary is "advertised" with a publicly accessible JSON-formatted .notary file containing hostname and port information along with the notary's public key.

Users can add a new notary to their browser's list of alternatives by requesting (i.e., clicking on) the notary's .notary file. If they later decide that a notary is no longer trustworthy, it can be removed at will. In his talk, Marlinspike calls this "trust agility" and says it is an essential feature of any CA-replacement scheme. In practice, he observes, CA trust cannot be revoked, because doing so (even when a CA is shown to be unreliable, such as Comodo) cuts off access to thousands of legitimate and uncompromised sites. For now, the GitHub site also hosts a list of known notaries, numbering around 40. The extension itself comes with a pre-loaded set of notaries to get started with.

Marlinspike also emphasized in his talk that Convergence's user-controllable, multiple-notary system does not hinge solely on whether or not each notary uses the Perspectives approach. Instead, the key factor is that the user has control over a dynamic set of trusted notaries. Some notaries could attempt to verify sites through other means, including DNSSEC, and the framework would still function for users. The user is responsible for setting his or her own "threshold" for accepting or rejecting a site's identity, based on what the notaries report about it.

Problems and criticisms

Marlinspike argued that Convergence could replace the CA system entirely if the majority of browser vendors got behind it — chiefly because no change is required of site administrators; their existing SSL certificates function just as well in Convergence's identity check process as they do today. But the user-configurability and flexibility of the system that Marlinspike regards as Convergence's strong suit is seen as an inherent weakness by the Chromium/Chrome team.

Google's Adam Langley wrote a blog post about the issue in September. He claimed that user statistics indicate "99.99% of Chrome users would never change the default settings," and as a result, the default set of notaries shipped with the browser would need to offer extremely high uptime and handle a tremendous traffic load. That, in turn, would mean that "Google would end up running the notaries. So the design boils down to Chrome phoning home for certificate validation," and Convergence support is therefore something that Google is not interested in adding.

Langley also cited two problems that Convergence cannot currently overcome: connecting to "internal servers" and captive portals. Langley does not elaborate on internal servers, but probably means intranet services that cannot be queried by notaries outside the internal network. Captive portals are a bigger problem, because they are widespread in public WiFi hotspots. Specifically, the issue is that a captive portal intercepts all HTTP and HTTPS traffic before the client sign-on is complete, so the browser cannot contact any notaries to verify that the portal itself is who it claims to be and not a clever phishing site.

Marlinspike addressed captive portals at the end of his talk, in terms of a lingering open question. Based on his slides (which show hypothetical notaries run by personally-trusted organizations like the Electronic Frontier Foundation), he does not seem too concerned about Langley's claim that Google would end up shouldering the burden of operating the world's notaries. Marlinspike also referred to what he called "the Citibank problem", where the Citibank URL transparently redirects different HTTPS requests to different internal servers with separate SSL certificates, thus making it impossible for notaries to verify the certificate by making independent requests. He did not have a solution, but did point out that Citibank is the only site known to suffer from this problem.

But despite his concerns, Langley was not all negative; he praised the Convergence extension as something worthwhile for those who wish to use it, and said that by coding it, Marlinspike "has already done a thousand times more to address the problem than almost anyone else." For its part Mozilla seems equally non-committal towards including the Convergence system in the future. Daniel Veditz said in a comment on the Mozilla Security blog that he was "intrigued by the Perspectives/Convergence experiments and we're definitely watching to see how they work in practice and at scale. We have no plans to build either one into Firefox at this time." There does not appear to be any public comment on Convergence from either the Internet Explorer or Safari teams.

Regardless of whether or not it ever appears as a built-in option, reality is that users with a mistrust of the CA system can use Convergence today to completely replace the default certificate-verification mechanism in Firefox. For some, that will probably be enough. Unfortunately, since the Black Hat talk, there has been little in the way of developing Convergence further as an open source project. There is a mailing list that has only archived a few messages, and the documentation — particularly for the protocol — is sparse. There is clearly sufficient interest in replacing the CA system to spawn work on a distributed, open source solution, but whether it remains a niche service like Tor or survives to affect the mainstream Web is entirely up in the air.