Browser Extension Defeats Internet Eavesdropping

Pickens writes to tell us that researchers at Carnegie Mellon University have created a simple system to help prevent man-in-the-middle attacks. Using a preset list of friendly sites called 'notaries,' the new 'Perspectives' system helps users to authenticate sites that require secure communications. Additionally this should help with the recently debated solution implemented by Firefox that has so many users frustrated and confused. "By independently querying the desired target site, the notaries can check whether each is receiving the same authentication information (a digital certificate), in response. If one or more notaries report authentication information that is different than that received by the browser or other notaries, a computer user would have reason to suspect that an attacker has compromised the connection."

Excellent!!

Now certs can finally be about the way they are actually used. Encryption. This should put an end to the argument that verifying encryption without verifying the identity of the third party allows man-in-middle attacks.

Re:Excellent!!

So, how exactly can you tell the difference between the third party and say, the man-in-the-middle?

Since you claim to be able to do so without being able to verify the identity of the third party?

Certificates were never about encryption. They were always about identity. As in I possess a unique item (a specific sequence of random digits, called a "private key") that I can use as a token and present at my discretion alone, to prove my participation in some activity without being physically present. In other words, the token is a proxy, and thus serves to identify the presenter.

The fact that this "key" has some unique properties in that through some fancy math, I can prove that I can access and use this "key", but not have to disclose it to you is what makes it useful for other tasks, such as encryption and digital signatures.

Self-signed certificates are useful only to indicate that you are having a conversation with an anonymous person, and NO assertions about the identity using the private key can be made.

You are free, of course, to put an end to any argument requiring intelligence to participate due to your obvious lack thereof.

The primary problem with certificates, IMHO, is the fact that within the certificate itself (or even the CSR for that matter), there are no assertions whatsoever as to the private key management and access controls in place.

Therefore, I find it amusing that there are Certification Authorities that are willing to make assertions as to the authenticity of any entity possessing access to the private key of that certificate being, in fact, the entity represented in the meta-data surrounding the public key in the CSR/certificate.

There is no way to know if a webserver is protecting its certificate private key at all (e.g. and serving it up as a normal document that anyone can request) without PBE (Password Based Encryption) in PKCS#8 PEM-encoded format, or whether the key was generated within a FIPS-140-2 Level 3 or higher device and cannot be exported outside of the security boundary/device.

Without that knowledge, you cannot determine an informed level of trust with which to associate the identity represented by the certificate.

Assertions of Identity require the attribute of uniqueness. I am underwhelmed at the lack of any framework or standards to define, measure, and assert probabilities that one's unique random sequence of digits (private key) is, in fact, unique.

Re:

If someone is at the root "In The Middle" point, between a client and the WAN, they can forge the Certificate Authority transaction to represent their cert as valid, claiming to be whoever they want.

There is no "Certificate Authority" transaction. The CA signature on the site certification is verified locally against a whitelist of CA public keys built into the web browser. The fact that anyone can create their own self-signed key for any domain is exactly why such keys do not establish identity, making MI

Re:Excellent!!

Problem is it doesn't work if the Man-in-the-middle is between both the "notary" trusted authority and the end-user client. (i.e. the MITM attack is done on the server-end)

It does make the attacks less realistic to perform, to be sure, but it still doesn't provide the same assurances which signed certificates claim to. In a sense it's the same system, except the only check performed is that the "notary" (i.e. certificate authority) only does a fairly simple check.

So; it'd be good, it'd improve things, but it wouldn't end the debate, and you can bet VeriSign would oppose it in any way they can.

Re:

Before anyone else comments on this, I'll clarify:

Problem is it doesn't work if the Man-in-the-middle is between both the "notary" trusted authority and the end-user client. (i.e. the MITM attack is done on the server-end)

The MITM attack would have to be in-place from the moment the self-signed cert is first used, because the "notaries" keep logs and would notice a change. Again; it makes an MITM attack much more unrealistic, and I'd definitely be in favor of this being using, but I don't think it'll close the debate.

Re:Excellent!!

The MITM attack would have to be in-place from the moment the self-signed cert is first used, because the "notaries" keep logs and would notice a change.

No, it would need to be in place before the moment that the self-signed cert is first reported to the notaries, if the functionality of reporting such mismatches were enabled, which it apparently is not by default at least now.

But what do they do even if it has changed over time? After all, if the idea is to render authority-signed certs unnecessary, wouldn't you expect servers to abandon them as they expire, replacing them with self-signed certs? Is that going to be flagged as risky?

Re:Excellent!!

This is in the FAQ. From TFA:

Q: But what if an attacker takes over all paths to the destination?

A: There are two answers to that. Please see our academic paper for a detailed security analysis.

1) Perspectives actually keeps a record of the keys used by a service over time. Thus, even if a powerful adversary is able to take over the whole Internet (scenario L_server in the paper), clients can still detect the key as suspicious because the key has recently changed. If the attacker is able to compromise all paths for a long time, then you are in trouble, but then again such a powerful adversary could also fool the so-called "verification procedures" of many certificate authorities, which often consist of a one-time email verification.

2) Even though a powerful adversary can defeat the system, it makes man-in-the-middle attacks much harder. Today an attacker must only be on the path between you and the destination, which isn't very hard. Think about an open wireless network, or the recent DNS attacks which compromise a targeted DNS resolver. Being on all links is much harder, and in the end security is nothing but making an attack harder.

Re:

I can see having multiple paths to your destination host (the server) will probably eliminate most MITM attacks under this system. However, our presumption of honesty is with the ISP's of course. If they decide to go "man in the middle" again (reaching a little for argument's sake) at the request of the government (or otherwise) are all bets still off? In other words, if all paths are considered to be compromised/under attack before the first use of the Notary system, can it still be considered effecti

Does not work if comprimised on site side

Interesting idea, but it will not work if the man-in-the-middle is hijacking the websites connection rather than the users.

Re:Does not work if comprimised on site side

Halfway correct. The Perspectives user can also specify a time period over which the certs must be consistently observed (we don't default to using that right now, because it makes new websites not appear). Using this setting, Perspectives can help avoid short-lived attacks against the connection to the webserver.

The motto behind this is roughly "You can fool all of the browsers some of the time, and some of the browsers all of the time..." - but an adversary who can hijack all connections to a site for a long period of time will defeat Perspectives.

    -Dave (one of the researchers on the project)

Re:

this is probably a stupid question.

Making a (possibly incorrect) assumption
---
In general, a MITM attack is either going to attack a user or a site. Namely, I'm going to interpose between the site and all users, or between a user and all sites.
---
In the former, if the attacker gets there early enough, how does the notary help? Especially as most sites where this would be in play are only single homed.

In the latter, doesn't this just add an additional burden to MITM attacking the notaries (i.e. intercept th

But who trusts their notaries?

The idea of "notaries" is essentially the same idea as having the Certificate Authorities: a third party who is considered trustworth and sufficiently dilligent that the third party would take the appropriate measures to verify something before signing off on it.

Who picks these people/companies?

Why not use a system like PGP, building a web of trust?

Disclaimer: I am a SC Notary Public.

Re:But who trusts their notaries?

The idea of "notaries" is essentially the same idea as having the Certificate Authorities: a third party who is considered trustworth and sufficiently dilligent that the third party would take the appropriate measures to verify something before signing off on it.

No it's not. These notaries don't sign anything and don't guarantee anything.

They just tell you what they see (which is useful because it's unlikely than a man-in-the-middle between the client and the site is also between the notary and the site), and what the saw before (so you can check certificates that the site used before you first visited it).

Who picks these people/companies?

Probably not important, because you check 3 or 4 (out of thousands) notaries around the world before deciding whether a certificate looks OK or not. So it's not easy to setup a "bad notary" that actually works.

I think this a promising idea.

Re:But who trusts their notaries?

I think the point is that a large-enough number of candidates plus a random selection equals statistical trust - the larger the base, the less likely it is that there isn't at least one uncompromised notary in your random sample.
A CA will always have the single-point-of-failure problem. While infiltrating Thawte certainly isn't something your average chinese hacker kid can do, it is certainly within the abilities of the NSA, or the KGB. The "web of trust" approach and the "we pick someone at random from a large crowd" approach both make it prohibitively expensive to compromise the sources of trust.

If you pick 5 sources at random, even from a crowd where 50% have been compromised, you still have a 1-(0.5^5) ~= 97% chance of having at least one uncompromised trust source. That's a pretty good record against an enemy who could compromise half of what could be millions of candidates.

Too much centralized trust

If you have a central trusted key server, there's no problem, and you don't need this. The whole point of public-key encryption is to eliminate the need for a central key server. How vulnerable is this new thing in a world with a large number of phony "notary" sites?

People used to talk about voting-based "web of trust" approaches, but that stopped working when the bad guys got zombie farms.

Some many reasons this is a bad idea:

1. Bringing down notaries would bring down all SSL/TLS traffic 2. Compromising the extension itself could allow for proxying of SSL traffic; exposing private information 3. Using the the notaries increases the footprint of SSL traffic; increasing the attack surface

band aids

This will have some effect, but it really is a band aid. If the certificate authorities would be doing their jobs and browsers would be more strict about using 'bad' certificates then this problem would not exist in the first place.

The greed of the certificate issuers is what has devalued the security.

Multiple layers of such security are not the same as a real solution.

Easy DoS Attack

Folks,

Nice try, but this scheme is a bad idea. It opens up a really easy DoS attack. All the attacker has to do is present a bogus certificate or SSH host key to a quorum of the notaries. BAM -- the server is now blocked. In fact, if the attacker can do this over a sustained period, he can masquerade as the actual server.

There's a reason why PKI works the way it does. There's a reason why you should use certificates or key pairs for authentication. The proposed system doesn't really help. Given that you can get a real SSL certificate for $15/year these days, only laziness leads to the use of a self-signed certificate.

I read the darn paper (yeah, yeah, I know, this is Slashdot, I'm not supposed to do that). They have a DoS column in their table in the Security Analysis section but don't discuss DoS in the text at all. Notaries need to be well known and are thus obvious candidates for a DNS-based attack. Next!

--Paul

That's what certificates are for.

Certificates from trusted parties should be used to certify that the certificate signed to belong to www.yourbank.com actually does belong to yourbank.

When certificate authorities break down, and issue www.yourbank.com certificates to somecrook, things break down.

The master certificate of the certificate authority that issues such bad nonsense should be revoked ASAP, and things can go on as designed.

Just an extra hoop?

But in a MitM attack.. If the DNS can be intercepted and rerouted to a spoofed site.. or the cert can be intercepted on the fly and regenerated.. why can't the information sent back from the notary also be forged?

Seems like an extra hoop for hackers to jump through but not an impossible one.

Re:

From the project's website:

"Q: But what if an attacker takes over all paths to the destination? ...

A: Perspectives actually keeps a record of the keys used by a service over time. "

Re:

The notaries are already known, which mean the browser plugin already has their certs. This is the same idea as 'Trusted certificates", except it doesn't require the site your visiting to have their individual certs signed.

Re:Only obfuscation

Sorry, I fail at reading comprehension today, let me try that again.

Ok, so lets say you try to browse to https://mybank.com/ [mybank.com] but there's a MitM intercepting your connection. When you first connect, the plugin should be able to get a fingerprint of the mybank.com cert. The plugin then asks the notary to verify that fingerprint. The notary connects to mybank.com and reports back the fingerprint. If they match, there's no MitB intercepting the secure communication (at least, not unless the MitB attacking from the network of mybank.com,) If they don't match, that means the two of you aren't seeing the same website, and something is *really* wrong.

Re:Only obfuscation

So the MiTM attacks the notaries as well. I call Fail.

You would have to successfully attack the notary. That will be harder than successfully attacking the client. Call fail all you like, don't bother with the plugin. Perhaps you should read the article though before posting.

Re:

From TFA:

"When Firefox users click on a Web site that uses a self-signed certificate, they get a security error message that leaves many people bewildered," says Andersen. Once Perspectives has been installed in the browser, however, it can automatically override the security error page without disturbing the user if the site appears legitimate.

Apparently Perspectives works around the Firefox wolf-crying. Sounds cool to me.