How does Convergence (CA replacement) prevent its notaries from being MITM'd as well?

Question

I have been looking into Convergence and how it works, but I cant figure out how it is effective against a MITM attack that happens near the target system. My understanding is that Convergence works by requesting a number of notary servers to check that they see the same SSL certificate from a destination server as you do. However, couldn't an attacker set up the attack in such a way that ALL traffic for the destination server goes through the attacker's server first? I have no idea how feasible that would be, but would it be more complicated than getting forged certificates from a CA (DigiNotar jokes aside)?

I know that this would only affect users who have not yet locally cached the destination certificate, so perhaps this is less of an issue. Still, it seems less than ideal. Just trying to figure out if Convergence is a solution to the problem or if its just a different kind of problem.

Answer 1

Details on Convergence are to be found in the Perspectives Project, notably the corresponding Usenix article.

An attacker able to "hide" the server from all notaries (i.e. an attacker working over the local network of the server, mostly) is what the authors call the L_server model. Ultimately, that attack "works" with default notaries, which use "network perspective". Namely, the notaries will see the attacker's certificate as being "a new certificate for the server", which is valid. However, as soon as the attacker ceases the active attack, the old certificate becomes visible again, and this raises alert flags in the notaries: a certificate update is certainly valid, the reappearance of an old certificate is suggestive of foul play at work.

However, nothing prevents notaries from using other validation strategies, including CA-based validation, which has its own issues but resists MitM.

There are two main ideas in that system:

• Delegate validation to external servers (the notaries), using several with a consensus quorum to avoid single points of trust. This kind of delegation already exists in the context of the X.509 bestiary, under the name SCVP (but the Convergence protocol is quite simpler).

• Have notaries use their memory to improve security. Where a normal SCVP server would rely on context-free validation (the true X.509 way) with maybe a bit of short-time caching but only to save on CPU costs, Convergence notaries primarily rely on temporal stability: they assume that SSL server certificates usually remain unchanged for one or several years, for a given server; hence they can simply check that a SSL server certificate is still the same than before. X.509 and SCVP could deal with a server getting a new certificate every 5 minutes, which is awesome but completely useless in practice.

A cornerstone of the Convergence reasoning is that if an attacker can successfully defeat the checks performed by the notaries, then he will also be able to impersonate the server when talking to traditional CA, and thus could also defeat the traditional CA model. Hence, security-wise, Convergence is no worse than the present situation. Note that X.509 could do much better; in particular, revocation is not really supported by Convergence, and Convergence is no worse than traditional CA mostly because existing clients tend not to check revocation anyway.

So really Convergence is not about making SSL more secure, but rather about killing off existing CA without lowering the overall security.

Potentially, a notary could run any validation process it wishes, including normal X.509 path validation (and then avoid the kind of MitM that you suggest). Since one could expect that there will be much fewer notaries than clients, and those notaries would be more "security aware", we can conclude that at some future point Convergence would actually improve Web security. The most immediate consequence of widespread Convergence usage, though, would be a shift in power: the Game Master would no longer be Microsoft (who decides which CA go into the list recognized by default by Internet Explorer) but rather whoever runs the notary with the best network connectivity that clients would use by default (presumably Google).

Answer 2

The Convergence project is based on the Perspectives Project by Carnegie Mellon University. The Perspectives Project has a bit more information on this. (See also their paper)

If the attacker sits near the target system, that would be possible, but really hard to execute. From the paper:

Lserver + k · nm Compromise: This attack is stronger than the previous Lclient + k · nm scenario, since control over the destination service’s link means that even legitimate notaries will observe the attacker’s key. As a result, even if fewer than q notaries are compromised, the client relies entirely on temporal safety.

Where "temporal safety" is defined as:

Instead, we use the concept of “temporal safety”, which means that a client will be safe as long as its quorum duration threshold is larger than the actual duration of the attack

The paper also says to that:

While our model allows any network or notary component to be compromised, we borrow from Abraham Lincoln and assume that an attacker “can fool all of the [components] some of the time, and some of the [components] all of the time, but it cannot fool all of the [components] all of the time.” That is, we assume that attacks are either: (1) localized to a particular network scope or (2) of limited duration, since a larger attack is more easily detected and remedied

So this seems to be a problem if no key is cached by the client and the notary servers (since they cache the key, too). If the attacker can fool all systems all the time, it would be possible. But it should still be more secure than now, where we have a single point of failure.

Answer 3

My understanding of this works as such:

If an attacker has all of your traffic forwarded though their server then yes they could STOP the traffic to the notaries.

They could not modify the traffic between the client and the notaries because the client already has a copy of the notaries certificate stored locally so if the response from the notary doesn't match the certificate the client has stored the client shouldn't accept the response.

[EDIT]

Currently there is a fork of the Convergence notary server that will be using Google's help (Google certificate lookup) to help verify that the certificate has been seen consistently.