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 (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.
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
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
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.
to post comments)