Slashdot Log In
Browser Extension Defeats Internet Eavesdropping
Posted by
ScuttleMonkey
on Mon Aug 25, 2008 12:27 PM
from the until-they-build-a-better-idiot dept.
from the until-they-build-a-better-idiot dept.
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."
Related Stories
[+]
How To Build a Quantum Eavesdropper 67 comments
KentuckyFC writes "Quantum encryption is perfectly secure, in theory. In practice, however, there are loopholes. Now Japanese scientists have designed a quantum eavesdropper that exploits one of these loopholes to listen in to quantum conversations. QC's security arises from the impossibility of making a perfect copy of a quantum object without destroying it — so the sender and receiver can always tell if they've been overheard. But it turns out that an eavesdropper can make imperfect copies and use them to extract information from a quantum message without alerting sender or receiver (abstract). The Japanese design does just this. That should worry banks and government agencies that have begun to use some of the commercial quantum encryption systems now available."
[+]
Technology: Firefox SSL-Certificate Debate Rages On 733 comments
BobB-nw points out the ever more raucous debate over the way Firefox 3 handles self-signed certificates. The scary browser warnings have affected a number of legitimate sites (such as Google AdWords and LinkedIn) that didn't renew certs in time. Lauren Weinstein loudly called attention to the problem early in July. "If you visit a website with either an expired or a self-signed SSL certificate, Firefox 3 will not show that page at all. Instead it will display an error message... To get past this error page, users have to go through four different steps before they can access the website, which from a usability standpoint is far from ideal. This way of handling websites with expired or self-signed SSL certificates is bound to scare away a lot of inexperienced users, no matter how legitimate the website is."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Excellent!! (Score:2, Insightful)
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!! (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.
Parent
Re: (Score:2)
Better yet, refer to this post.
http://slashdot.org/comments.pl?sid=656323&cid=24739889 [slashdot.org]
Re: (Score:3, Interesting)
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: (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 MI
Re: (Score:3, Insightful)
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 qui
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
'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 techno
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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
Re:Excellent!! (Score:5, Insightful)
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.
Parent
Re: (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:4, Insightful)
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?
Parent
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.
Parent
Re: (Score:3, Interesting)
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
Good Start.... (Score:2)
unless the site was compromised and everyone started receiving the false certificate. Maybe they could also have a store of previous certs to compare it against?
Re: (Score:2)
Browsers already do store previous certs, and warn you if they change. This is for the initial query, I think.
Re: (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: (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: (Score:2)
That was my first thought when reading it, it depends on where you place the 'middle'.
If the middle is on the network of the hosting facility of the server that is being impersonated then this system will not work, especially not if it is installed very early (because then there will be no change to detect).
Does not work if comprimised on site side (Score:5, Interesting)
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)
Parent
Re: (Score:3, Insightful)
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
Re: (Score:2)
One: See angio/Dave's reply.
Two: Hijacking the website in, or all connections from a datacenter is usually a lot more difficult and expensive than going down to your local cable/DSL/whatever hub and playing maintainance crew, or taking over your WLAN router (or the one in the hotel you're staying in).
Case in point: Not very many banks are robbed anymore the old-fashioned way. But there's a lot more going on with ATM machines than the banks let us know.
What about signing? (Score:2)
I thought the whole point was to have an "authority" (like verisign etc) sign your certificate. So MitM can't just swap in their own cert because to change it would break the signature?
Or are they just shooting for a free alternative? signed SSL certs are more expensive than some smaller places want to bother with.
But who trusts their notaries? (Score:5, Interesting)
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? (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.
Parent
Re:But who trusts their notaries? (Score:5, Interesting)
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.
Parent
Compromising a CA (Score:2)
Bruce Schneier once chatted with the president of Verisign about how much it would cost to compromise Verisign's root signing key.
They figured that organized crime could swing a leveraged buyout for USD15 million.
(Any errors in the above are my fault).
Re: (Score:2, Interesting)
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 th
Too much centralized trust (Score:5, Insightful)
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: (Score:5, Interesting)
band aids (Score:4, Interesting)
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: (Score:2, Interesting)
Easy DoS Attack (Score:5, Interesting)
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
back and forth (Score:2, Funny)
"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"
DNS as a possible additional route of verification (Score:2)
I thought of something recently, which I'm not sure if it is a tremendously stupid idea, or has some merit, and I've been wondering - why couldn't DNS possibly be used as an additional way to verify SSL? Here's what I mean - right now, when you connect to a given server, you use DNS to lookup the server's IP, then connect to the server, which sends you back a certificate with the public key of the server. Unfortunately, you have no way to verify that the public key you are purportedly
That's what certificates are for. (Score:3, Insightful)
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? (Score:3, Interesting)
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: (Score:3, Funny)
Easy: Just have the notaries register with Verisign.
Defeats Internet Eavesdropping? (Score:3, Insightful)
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.
Re: (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: (Score:2)
What if the mim decides to not get between you and the notary site? What good does this plugin do you then?
Re: (Score:2)
Well gee, let me think.... then the plugin notices that the cert for the notary has changed, and knows there's a MitM, attack fails.
Poster below this this thread already pointed out how the system *does* fail however. MitM has to attack target website, as opposed to the user's net connection. That way, both the user and the notaries will get the MitM certs.
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.
Parent
Re: (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: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.
Parent
Re: (Score:2)
Where are my mod points when I need them!
Re: (Score:3, Informative)
From TFA:
Apparently Perspectives works around the Firefox wolf-crying. Sounds cool to me.
Re: (Score:2)
Apparently Perspectives works around the Firefox wolf-crying.
I agree, I was objecting to the categorization of the Firefox behavior as a "solution" in the summary.
That is, this extension and working around the Firefox problem should be seen as separate goals.