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."

Comments

Excellent!!

[shaitand]

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!!

[Anonymous Coward]

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:Excellent!!

[kestasjk]

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:Excellent!!

[kestasjk]

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!!

[archatheist]

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:Excellent!!

[mccabem]

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 effective in some way?

Thanks!
-Matt

Re:Excellent!!

[Anonymous Coward]

You are still completely missing the point here. You cannot (securely) use asymmetric encryption without knowing that the public key provided to you ACTUALLY BELONGS TO THE PERSON WHO YOU ARE TRYING TO COMMUNICATE WITH. This is the point of certificate authorities. They're a trusted third party who verifies someone's identity, thus allowing secure communication. So no, certificates are not USED to provide encryption. It's USED to verify identity. Yes, it is vital to the encryption process, but you are not correct in your assumption and the AC is correct in questioning your intelligence.

Re:Excellent!!

[JesseMcDonald]

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 MITM attacks possible. By contrast, CA-signed certificates can't be forged without first breaking (or otherwise acquiring) an established CA's signing key.

A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient. There's no way to tell whether a self-signed certificate belongs to the intended recipient or a MITM, which renders the encryption useless against a determined attacker.

Re:Excellent!!

[camperdave]

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.

Can you not, with reasonable certainty, be confident that the anonymous person you're dealing with now is the same anonymous person who was using the key last month? After all, the exchange of keys is supposed to take place over a secure channel.

Re:Excellent!!

[camperdave]

A middleman is a third party. At least, that's in my definition of third party.

... and I am self by definition, so if I can't trust self signed certificates, I'm in real trouble. Of course, it may be wise of me not to trust me, because if it were cookies instead of data, well I'd have no cookies left (especially if they were the mint Girl Guide cookies).

Re:Excellent!!

[shaitand]

'You are still completely missing the point here.'

You are still completely missing the point here. It doesn't matter whether you can securely use the encryption without assurance the public key belongs to the person who you are trying to communicate with. That was a given and understood point from the start, both you and the other AC are obsessed with a point that was never in dispute.

The point is that the certificate authorities FAIL to provide that assurance and further represent a burden that this technology now alleviates. With this technology that assurance is provided without the need for the biased and profit motivated certificate authorities.

Since the certificate authorities FAILED to provide that assurance, implementing the process only served to provide a less than secure encryption process that did at least prevent sniffing without a man in the middle attack. That much could be provided without the authorities at all.

With this new extension the level of security and assurance envisioned for browser security (and pretended by those who chose to ignore the problems with the certificate agencies) can finally be achieved.

Problem solved, both sniffing and man-in-middle attacks thwarted. I won't go around questioning the intelligence of an individual who I believe to be ignorant. I will say that you have displayed a density that is rather impressive. I won't say as much for the other AC (who might actually be you) since he hasn't claimed credit for yet another post beating a dead horse that was adequately explained IN MY ORIGINAL POST.

Re:Excellent!!

[DragonWriter]

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!!

[sofla]

They're too expensive, and not worth it. People want a warm fuzzy feeling.

And impossible. You forgot to mention impossible. Identity is not provable. All that is provable, is possession of a token (or, multiple tokens, such as access to email address, telephone, an apparently valid photo id...) that supposedly establishes identity. But most (all?) of these tokens can be faked. That's where trust comes in - sooner or later you have to blindly assume that an identity is genuine (if not for the token itself, then for the issuer of the token, or the issuer of the issuer...). So hang on to that warm fuzzy feeling. Its the best that we can hope for.

Re:Excellent!!

[JesseMcDonald]

I'm not trying to say that a CA-signed certificate is an absolute guarantee of identity. If you can actually trust the certification authority, and everyone follows all the rules and keeps their private keys secure, and the private keys aren't broken by brute force or cryptoanalysis, then the authentication will be valid. These conditions are implied in any security arrangement, and pointing out that they may not hold in any given implementation adds nothing useful to the discussion. Everyone is already quite well aware of that fact.

You aren't going to find absolute security anywhere. There is always the possibility that someone, somewhere, may fail to uphold their part of the protocol. TLS/SSL is still a significant improvement over systems without certificates or CAs, which would be insecure even if perfectly implemented.

P.S. A certificate signed by the actual CA is not a forgery. If such a certificate is false it merely means that particular CA cannot be absolutely trusted.

Re:Excellent!!

[QuoteMstr]

As others have mentioned, this "technology" (how I loathe that word) is still vulnerable to MitM attacks. It doesn't matter what you ask Alice and Bob when Eve controls all the responses. As for "biased and for-profit": there's no evidence they're biased. If you don't like one CA, see another. And as for being for-profit: unfortunately, money changing hands is by far the best authenticators available today.

Does not work if comprimised on site side

[TorKlingberg]

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

[angio]

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:Does not work if comprimised on site side

[spotter]

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 the request to the notaries and return a hunky dory a-o-k message). Don't attack the notaries, just prevent the message from ever reaching them. This can be solved with ssl, but then you've just moved the need for ssl to a different location.

I could be totally misunderstanding, haven't read the paper (trying to write my thesis to get out of school :), slashdot was a temporary distraction).

Re:Good Start....

[Mierdaan]

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:Good Start....

[Anonymous Coward]

... Maybe they could also have a store of previous certs to compare it against?

RTFA (I know, I must be new here...).

They do.

Re:Only obfuscation

[Rashkae]

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

[Sir_Real]

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.

But who trusts their notaries?

[querist]

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?

[ccguy]

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?

[Tom]

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.

Re:But who trusts their notaries?

[Anonymous Coward]

The idea of "notaries" is essentially the same idea as having the Certificate Authorities

Nope.

By having several "Notaries" you can ask verification of you do not need to put all your trust in a single party: Ask multiple Notaries and only accept if all return the same info.

If you want to include the possibility that one of those notaries goes bad (wonky connection, hijacked or simply not doing its job) than accept the info if the majority agrees on it.

Personally I think a method like this (which spreads the risk) will be better than a single chain-linked organisation (where you dangle at the end of that chain).

Re:But who trusts their notaries?

[redbu11]

Trust isn't the key problem with CAs.
The key issue is that CAs like Thawte or Verisign do not scale. They manually verify each certificate request, a very expensive and labor-intensive process. A customer ordering an SSL certificate for https://www.acme.com/ must provide CA with legal documents showing that (a) ACME corp actually exists, (b) he really works for ACME, (c) he is authorized to request the certificate, and so on..
All submitted documents are manually verified by the CA (at least in theory). Sometimes, they look up the company in a phone directory and call the public phone number to check that the requester really works for the company, etc.
That's why CA-issued certificates are so expensive; for example, 1-year Thawte SSL cert costs US $249. The certificate alone costs more than what a shared hosting with php5 and mysql would cost, per year!
Expensive, manual verification process is the key problem with modern CAs and "notaries" provide excellent solution to it.

Too much centralized trust

[Animats]

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:

[keithadler]

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

[jacquesm]

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.

Re:band aids

[Atriqus]

I have to agree about CA greed. Whenever I see a site using a Mozilla approved CA, my initial thought is no longer whether my connection is secure, but rather an acknowledgment that the site paid protection to Verisign that year.

Re:Only obfuscation

[Rashkae]

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

Ok, so lets say you try to browse to https://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.

Easy DoS Attack

[plsuh]

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

Re:Nothing to do with Firefox's nonsense.

[schwaang]

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.

back and forth

[ILuvRamen]

Yeah yeah yeah, there's a new thing that'll protect you 100% from hacks and then the next article is there's a new thing that can bypass all security protections and you're 100% likely to get hacked. If they're gonna keep running these stories, they might as well make them real:
"New anti-hacking methods developed. You drive to the web host's datacenter and sit down at the server that contains the site you want and open the HTML files from there"

Re:Now all ...

[Atriqus]

Well, as far as I can tell, the current system assumes verisign won't be compromised either.

That's what certificates are for.

[rew]

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?

[k1e0x]

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:Just an extra hoop?

[zippthorne]

Easy: Just have the notaries register with Verisign.

Still hackable, more difficult

[mathimus1863]

It seems that the MITM can accomplish his deception if he is sufficiently close to either the server or the client. If he's next to either of them, he can replace all the data going in or all the data going out, so that all I/O seems to be the same.

In other words, your officemate decides to bridge your network connection through his computer without you realizing he's switched your cables. It doesn't really matter what the notaries say, because he can manipulate all of them to say the same thing, since all their responses are routed through his computer first. Identically, if he's on the server side, he can modify all the outgoing notary requests so all notaries see the same thing.

With respect to that, there's not much that can save you. But, someone evil in the intarwebs who is randomly a few hops from either the server or client will no longer have the power to pull off a MITM. They have to compromise either network-bottleneck to break it. Actually it surprises me that no one thought of this earlier. It's a simple concept which appears to serve its purpose (at least until empirical evidence finds otherwise).

Re:Only obfuscation

[Qzukk]

the certificate will not validate

This is being done because admins are crying that users have to jump through hoops to use their website when they use certificates that can't be validated.

Defeats Internet Eavesdropping?

[Valdrax]

So, the way to defeat internet eavesdropping is to have a centralized service that double-checks all the websites you go to?

Does anyone else think this is mutually incompatible with any concept of anonymity online? In other words, this reduces the risk of one form of eavesdropping by having you accept an entirely different form of eavesdropping.