Browser Extension Defeats Internet Eavesdropping 194
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."
Re:Good Start.... (Score:3, Informative)
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.... (Score:2, Informative)
... 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 (Score:3, Informative)
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 (Score:5, Informative)
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:Does not work if comprimised on site side (Score:5, Informative)
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:But who trusts their notaries? (Score:5, Informative)
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).
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:Only obfuscation (Score:5, Informative)
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:Excellent!! (Score:5, Informative)
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:Nothing to do with Firefox's nonsense. (Score:3, Informative)
From TFA:
Apparently Perspectives works around the Firefox wolf-crying. Sounds cool to me.
Revamp the whole SSL thing (Score:1, Informative)
Maybe its time to do a clean slate and revamp the way SSL works. There have been too many patchworks, band-aids, antidotes, etc. Just as the way the MIT is working on doing a clean slate for the Internet, maybe someone should consider reconstructing SSL cert process from scratch. Just my 2 cents.
Re:Excellent!! (Score:3, Informative)
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!! (Score:5, Informative)
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:Some many reasons this is a bad idea: (Score:1, Informative)
Umm, yeah. That's a lot of handwaving there. I'll just address your first point, by mentioning the detail that notaries would count in the thousands, as opposed to a single one, or even a few. And I must say that point 2 and 3 are ... yep, mostly handwaving.
I'm sure you have an actual argument in there somewhere, and I'd be happy if you took the time to flesh it out a bit more than you've done so far.
Re:Excellent!! (Score:1, Informative)
The primary purpose of certificates is authentication. When self-signed certificates are used, they are used for two purposes: a) to allow the use of a standardized protocol which (in its most widely deployed implementations) requires server certificates and b) to authenticate the server as the same server which participated in the communication before.
Whether the issuing party properly verifies the identity of the applicant is indeed an issue, but that doesn't change the purpose of certificates. If you just wanted encryption, you wouldn't need certificates. You could just use random keys and Diffie Hellman key exchange. [wikipedia.org]
Re:Excellent!! (Score:3, Informative)
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.
Still hackable, more difficult (Score:2, Informative)
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 (Score:3, Informative)
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.
Re:Easy DoS Attack (Score:1, Informative)
"All the attacker has to do is present a bogus certificate or SSH host key to a quorum of the notaries."
What? No. It's a system where people who want to use a signed site automatically grab copies of the site's signature from other sources and compares them locally to determine trust. You pull signatures from notaries, you don't push your own signature out to them. Notaries aren't collecting signatures from users, they're polling and caching the signatures of requested sites.
To poison notaries, you'd have to either hijack each notary's individual connection, or hijack the actual requested site. Both of which are much harder than today's requirement (hijack the connection of your mark - Joe Random user you're trying to defraud/hack).
In the case where the target site has been hacked, well, being unable to access it due to confused notaries would be GOOD, considering the site is compromised.