Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Browser Extension Defeats Internet Eavesdropping

ScuttleMonkey posted about 6 years ago | from the until-they-build-a-better-idiot dept.

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

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

Excellent!! (2, Insightful)

shaitand (626655) | about 6 years ago | (#24739209)

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!! (5, Informative)

Anonymous Coward | about 6 years ago | (#24739717)

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!! (0, Redundant)

shaitand (626655) | about 6 years ago | (#24739951)

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

Via a browser extension that utilizes MULTIPLE third parties like this one I'd guess.

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

Clearly, you are the great and wise one who is unable to make a point without attempting slander.

'Certificates were never about encryption. They were always about identity.'

Certificates were never USED to verify identity, and have always been USED to provide encryption. How they were intended to be used or should be used is irrelevant. $15 will get you certs from a number of authorities that claim you are someone you aren't.

Re:Excellent!! (2, Insightful)

Anonymous Coward | about 6 years ago | (#24740795)

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!! (1, Insightful)

Anonymous Coward | about 6 years ago | (#24740223)

A private key cert, without any trust, defeats a very common attack: The eavesdropping man in the middle. If they are unable to alert the data stream, but can listen in, a public-private key session is all that's needed. It defeats such notable attacks as the NSA Wiretapping.

Certs, theoretically, were about trust, but quite frankly? Trust no one. Nobody wants actual verification and safeguards: They're too expensive, and not worth it. People want a warm fuzzy feeling.

Re:Excellent!! (1)

nog_lorp (896553) | about 6 years ago | (#24740271)

The MITM argument does not differentiate between self signed (for encryption only) and CA-signed (for identity verification) use of certs. It is an illogical argument to say Certs are not useful for encryption due to MITM concerns, but certs are useful for establishing identity.

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.

Re:Excellent!! (1, Informative)

Anonymous Coward | about 6 years ago | (#24740859)

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!! (2, Informative)

JesseMcDonald (536341) | about 6 years ago | (#24740903)

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!! (1, Insightful)

Anonymous Coward | about 6 years ago | (#24740463)

I think the best part of this idea is not the technical part, but that of referring to the authentication server as a "Notary". This is a term that is much more familiar to novices.

Sometimes simply using a more well-known term for a process is enough to help people understand, and subsequently use with the proper understanding and suspicion.

Re:Excellent!! (1)

ksd1337 (1029386) | about 6 years ago | (#24740761)

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

Re:Excellent!! (2, Interesting)

camperdave (969942) | about 6 years ago | (#24741165)

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!! (4, Insightful)

kestasjk (933987) | about 6 years ago | (#24739813)

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!! (2, Informative)

kestasjk (933987) | about 6 years ago | (#24739849)

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!! (5, Informative)

archatheist (316491) | about 6 years ago | (#24739889)

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!! (1)

techno-vampire (666512) | about 6 years ago | (#24740377)

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

A: Unless the attacker is the service providing your connection (This may not be your ISP; if you're using DSL it might be your telco, or a big DSL provider. If you're on dial-up, your ISP might be leasing the PoP from some other national or local company, such as UUNet.) such control is almost impossible, and at best, highly unlikely. There would have to be at least one choke point, or possibly a choice among a very small number of them, for this to work. Even then, the MITM would have to control them all to be able to take over all paths to the destination. If there's even one path they don't control, the attempt fails.

My ISP is the People's Republic of China (1)

davidwr (791652) | about 6 years ago | (#24740437)

I've been screwed since 1949.

Re:Excellent!! (1)

Adrian Lopez (2615) | about 6 years ago | (#24740533)

"clients can still detect the key as suspicious because the key has recently changed"

That only works if the client has a copy of the proper certificate. If this is the first time the client is connecting to the "secure" server, a man-in-the middle attack that also intercepts communications along the path to the notary will succeed.

Re:Excellent!! (2, Interesting)

mccabem (44513) | about 6 years ago | (#24740369)

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!! (1)

slashname3 (739398) | about 6 years ago | (#24741143)

Actually all of this becomes mute since most end users will simply click OK or Yes when prompted that they keys have changed and may indicate something bad. Training end users to understand what is being reported is a never ending process and ultimately a game that can not be won. The attacker always has the advantage.

Re:Excellent!! (1)

CodeBuster (516420) | about 6 years ago | (#24740909)

Wrong. This may increase the difficulty of the MITM attack by some constant amount (the number of notary servers checked) but does not foreclose the possibility that the notary requests themselves might be intercepted and impersonated by the MITM so the attack remains theoretically viable. That is the problem with MITM, it has more lives than Schrödinger's cat [wikipedia.org] . Just when you thought that you had gotten rid of it it comes back in a revised form. The best solution thus far is and remains the inclusion of trusted root certs with the hash verified build of the OS that you are using which can then be used for checks and even this solution is not perfect (although it makes breaking the authentication at least as difficult as breaking the encrypted session itself which tends to discourage attacks on the authentication or at least not to favor them over simply breaking the session encryption).

Good Start.... (1)

jeffy210 (214759) | about 6 years ago | (#24739215)

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

3p1ph4ny (835701) | about 6 years ago | (#24739233)

Browsers already do store previous certs, and warn you if they change. This is for the initial query, I think.

Re:Good Start.... (1)

funnyguy (28876) | about 6 years ago | (#24739441)

What browser do you use? We're talking about Authentication of certificates. If Paypal changes its certificate to a new one that is Authenticated by a trusted CA, nobody gets a "warning" that the certificate has changed.

If you self-sign certificates, and explicitly trust specific certs, then you would be warned if it changed.

Re:Good Start.... (3, Informative)

Mierdaan (134219) | about 6 years ago | (#24739309)

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.... (1)

funnyguy (28876) | about 6 years ago | (#24739527)

So then that proves it. Change your cert for valid reasons, and you get blocked because it looks like a MITM attack at the server.

If the Notaries trust an alternative source of authentication such as a trusted CA, then they could potentially look past this, but isn't the point of a Notary for authentication to avoid that all together?.

Re:Good Start.... (1)

Mierdaan (134219) | about 6 years ago | (#24739929)

No it doesn't. The first thing they'll check is whether or not the client is receiving different keys than the notaries; if everything's in agreement, I can't imagine it'd throw a warning about that. People do change their certs for legitimate reasons, after all...

Re:Good Start.... (2, Informative)

Anonymous Coward | about 6 years ago | (#24739337)

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

funnyguy (28876) | about 6 years ago | (#24739383)

Ya. This is ONLY good if the MITM attack is near the client or inbetween the client and the server. If the MITM attack is at the server or the near the server, this is pointless and would just provide a false sense of security.

I was thinking the same thing about using historical certificates. The bad thing here is when a host changes its certificate for a valid reason it would lose trust for some time.

Re:Good Start.... (1)

jacquesm (154384) | about 6 years ago | (#24739521)

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

Openning a New avenue of attack? (0)

Anonymous Coward | about 6 years ago | (#24739221)

I don't know the particulars, but might not a hostile be able to bring down entire segments of the network by intentionally giving incorrect information?

Only obfuscation (0)

Meneth (872868) | about 6 years ago | (#24739237)

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

Re:Only obfuscation (2, Informative)

Rashkae (59673) | about 6 years ago | (#24739361)

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 (1)

fatboy (6851) | about 6 years ago | (#24739463)

What if the mim decides to not get between you and the notary site? What good does this plugin do you then?

Re:Only obfuscation (1)

Rashkae (59673) | about 6 years ago | (#24739565)

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 (5, Informative)

Rashkae (59673) | about 6 years ago | (#24739613)

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 (1)

fatboy (6851) | about 6 years ago | (#24740399)

Ah, OK. I should have RTFAed :) I still don't understand why this is needed. If there is a man in the middle, the certificate will not validate. What does this buy you, other than more complexity? I guess I should RTFA now :) >

Re:Only obfuscation (4, Informative)

Sir_Real (179104) | about 6 years ago | (#24739365)

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:Only obfuscation (0)

Anonymous Coward | about 6 years ago | (#24739643)

Perhaps you should read the article though before posting.

You must be new here.

Depends on where the MITM is. (1)

Ungrounded Lightning (62228) | about 6 years ago | (#24740819)

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.

It's easy to see how a browser plugin, which potentially has canned cerdentials for some notaries, could work even if the MITM is between the user and all the notaries.

But TFA is too sketchy to tell us what, if anything, prevents a MITM who is intercepting all traffic with the far end - both from the user and the notaries - from faking things identically for all the observers.

(Another risk is the MITM corrupting the download of the plugin - after which point all bets are off.)

Re:Only obfuscation (1)

denis-The-menace (471988) | about 6 years ago | (#24739381)

Where are my mod points when I need them!

Beware! (1)

RevVoice (1350871) | about 6 years ago | (#24739253)

They have spytech! THEY KNOW!!!

Does not work if comprimised on site side (4, Interesting)

TorKlingberg (599697) | about 6 years ago | (#24739273)

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 (5, Informative)

angio (33504) | about 6 years ago | (#24739405)

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 (2, Insightful)

spotter (5662) | about 6 years ago | (#24740987)

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

angio (33504) | about 6 years ago | (#24741077)

It only helps for a short period of time - say, a day or two. If the attack against the whole site is successful for longer than that, Perspectives will eventually say "okay, that key's been around long enough, it's good." The assumption is that sites will eventually notice the attack -- which may or may not hold. :-) One cool thing about Perspectives is that you can use it to monitor your own site... if Perspectives starts showing a different key than the one you're using, you know you have a problem.

Re:Does not work if comprimised on site side (1)

Tom (822) | about 6 years ago | (#24739617)

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.

Re:Does not work if comprimised on site side (1)

lubricated (49106) | about 6 years ago | (#24741075)

It'll also fail if mitm is hijacking the server.

What about signing? (1)

v1 (525388) | about 6 years ago | (#24739313)

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.

Re:What about signing? (1)

Free the Cowards (1280296) | about 6 years ago | (#24740095)

They accomplish different things. A true cert tells you that when you're talking to xyzcorp.com that you're really talking to XYZ Corp. of Bumfuck, IA and that this information was verified within the last year. This notary system would simply tell you that the xyzcorp.com you're talking to is the "real" xyzcorp.com, and not some spoofed version. For example, this technique would work for an anonymously run site, but a normal SSL cert would not allow that.

Of course the fact that you don't have to cough up money to the signing authorities is nice too.

Re:What about signing? (1)

robo_mojo (997193) | about 6 years ago | (#24740179)

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?

Unless the MITM can get his cert signed as well. Do you know all the authorities that your browser trusts by default? There are many others besides verisign.

Re:What about signing? (1)

TopSpin (753) | about 6 years ago | (#24740181)

Or are they just shooting for a free alternative?

The "just" part there is considered a problem. The argument goes that SSL would be ubiquitous if there were no cost, hassle, discloser requirements, etc. Imagine, for instance, that common web servers automatically generated self-signed certs as needed and that these certs were used to encrypt everything by default. This is how SSH servers (OpenSSL) typically work today.

As it is this isn't really possible because browsers erupt warnings, confirmation dialogs and other spasms when a self-signed cert is encountered. This is unacceptable for the bulk of users.

I have always thought that requiring encryption to be coupled with identity is a mistake. Identity needs encryption while encryption doesn't necessarily need identity; encryption is useful independently, regardless of what the security zealots claim.

$15 and a phone call to get a signed cert really is too much to ask. Some people have a difficult time understanding that.

How to fix it? I dunno.

Many around /. advocate eliminating the browser machinations over self-signed certs. This will never happen; compromising what limited integrity contemporary SSL provides will not be supported by the powers that be. IETF will not sign on to it. Verisign won't. Forget it. Any browser vendor foolish enough to fail to comply will be lambasted as insecure and shunned by major institutions.

Call the existing system "legacy" and invent something new? Microsoft won't buy it. Scratch 80% of all web traffic.

IPv6 with it's mandatory IPsec support? See you in 2030 I guess.

P.S. this recent hubbub about Firefox and it's warnings about self-signed certs; this isn't new. Firefox, IE and other browsers have been doing this for years. FF 3.x behavior is not some new phenomena for slashdot to hyperventilate over.

Now all ... (1)

SlashDev (627697) | about 6 years ago | (#24739347)

... they need is a way to secure those "Notaries"...

Re:Now all ... (2, Insightful)

Atriqus (826899) | about 6 years ago | (#24740047)

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

But who trusts their notaries? (4, Interesting)

querist (97166) | about 6 years ago | (#24739375)

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? (5, Informative)

ccguy (1116865) | about 6 years ago | (#24739559)

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? (1)

Deadplant (212273) | about 6 years ago | (#24741087)

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

I think it is the same thing.
The notaries are simply 'certificate authority - lite'.

They are providing exactly the same service (a level of identity trust) as CAs. The mechanics are different, no signing certs, but the role is the same.

Re:But who trusts their notaries? (4, Interesting)

Tom (822) | about 6 years ago | (#24739569)

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.

Compromising a CA (1)

Beryllium Sphere(tm) (193358) | about 6 years ago | (#24739947)

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:But who trusts their notaries? (1)

Andrzej Sawicki (921100) | about 6 years ago | (#24740131)

Great odds, but doesn't that provide an attacker with a way to break the system? With enough notaries giving false warnings on purpose, a random pick of 5 will very oftet tell you not to trust a site regardless of its actual status. Or am I missing a way to eliminate the problem of false positives here (disregarding normal certificate updates).

Re:But who trusts their notaries? (2, Interesting)

Anonymous Coward | about 6 years ago | (#24739573)

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? (2, Interesting)

redbu11 (1343351) | about 6 years ago | (#24740295)

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/ [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.

Yea, that, or SITES CAN UPDATE THEIR CERTS! (1, Insightful)

HaeMaker (221642) | about 6 years ago | (#24739401)

Stupid solution for a stupid problem.

Re:Yea, that, or SITES CAN UPDATE THEIR CERTS! (1, Insightful)

Anonymous Coward | about 6 years ago | (#24739493)

Except the hundreds of millions of sites that can't even use authority-signed certs, if they're embedded in a package or piece of hardware, like a firewall. Stupid response.

Re:Yea, that, or SITES CAN UPDATE THEIR CERTS! (0)

Anonymous Coward | about 6 years ago | (#24740027)

Except the hundreds of millions of sites that can't even use authority-signed certs, if they're embedded in a package or piece of hardware, like a firewall. Stupid response.

! If they're embedded in your firewall, how do the notaries see them? Stupid response yourself.

Nothing to do with Firefox's nonsense. (0, Troll)

argent (18001) | about 6 years ago | (#24739415)

Crying wolf by making people jump through hoops for self-signed sites doesn't stop MiTM attacks, it just trains people to ignore warnings about self-signed certs. This is a scheme for adding a kind of web of trust to the "is this the same certificate as last time" check. It's a good idea, but it shouldn't be conflated with the Firefox overreaction to self-signed certs.

Re:Nothing to do with Firefox's nonsense. (2, Informative)

schwaang (667808) | about 6 years ago | (#24739743)

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.

Re:Nothing to do with Firefox's nonsense. (1)

argent (18001) | about 6 years ago | (#24739825)

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.

Re:Nothing to do with Firefox's nonsense. (1)

Korin43 (881732) | about 6 years ago | (#24740161)

Yeah. I was a little worried about not seeing any security warning when going to sites with self-signed certs, but what it is does when you suppress the error message is have the normal error bar says that perspectives has verified the site and blocked the security error. It's still there, but it's much less intrusive than Firefox's way.

Re:Nothing to do with Firefox's nonsense. (1)

Hyppy (74366) | about 6 years ago | (#24740993)

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

Firefox 3 cries wolf because it's true. Self-signed certificates are a security risk to virtually any normal user. If a web developer is too lazy or cheap to get a real certificate, I can only begin to imagine how lazy or cheap they are with the rest of their security posture.

Too much centralized trust (4, Insightful)

Animats (122034) | about 6 years ago | (#24739447)

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.

You want PKI without the I ? (0)

Anonymous Coward | about 6 years ago | (#24740797)

You know the "I" in "PKI" stands for "Infrastructure", right? How do you expect to have public-key encryption without a way of securely distributing the public keys? To prevent MITM you need to know that the public key really belongs to the party you want to communicate with. You either need some centralized authority (in other words, a CA) or you need the "web of trust".

Some many reasons this is a bad idea: (5, Interesting)

keithadler (562733) | about 6 years ago | (#24739511)

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

Re:Some many reasons this is a bad idea: (1, Informative)

Anonymous Coward | about 6 years ago | (#24740691)

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:Some many reasons this is a bad idea: (0)

Anonymous Coward | about 6 years ago | (#24740833)

To solve 1: Create notary tiers. Choose at least two notaries from Tier 1, at least one notary from Tier 2, and at least three notaries from Tier 3.

Tier 1 notaries would be fortresses: well-known, well-funded organizations to replace the Verisigns of today.

Tier 2 would be people you know personally, or your ISP, or some such.

Tier 3 would be any old anonymous volunteer out there.

The statistics math mentioned earlier explains how compromising 50% of all notaries still leaves you with a 97% chance of detecting the attack if you use as few as five notaries. With tiers, you have a 100% change of detecting the attack unless your particular Tier 1 notaries are compromised. If all of your Tier 1 notaries are compromised, you still have an overwhelming probability of detecting the attack. A successful attacker would have to defeat _all_ of your notaries.

If you trust Verisign to protect your certificate now, you could trust NotaryOne, Inc. to protect you in the future. But with notaries, you don't have to trust NotaryOne exclusively. You could add four, five, 10, or more other notaries to verify against. Even if NotaryOne and your ISP are compromised, your gNotary from Google will save you. If they are also compromised, your friend Nate in Australia will save you. Or Suzie in South Africa, or Pat in Chicago. Or some stranger named Wu. Or some Italian whose name is obvious computer-generated. Or your bank's independent notary pool.

If all of those are compromised, you have a lot more worries than your certificate.

Re:Some many reasons this is a bad idea: (0)

Anonymous Coward | about 6 years ago | (#24741053)

Isn't (2) here the same attack as compromising IE or Firefox?

I don't see it as more risk than we currently have.

Phishers Rejoice! (1, Interesting)

Anonymous Coward | about 6 years ago | (#24739531)

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

Overriding the security error page just because the site has self-signed cert that appears legitimate? How do you determine legitimacy? Just because a site has a self-signed cert doesn't mean its legitimate, it just means it has a self-signed cert. In fact, I prefer to be warned if I'm connecting to a site with a self=signed cert so I can choose whether to connect to the site or not.

Nothing good can come from hiding important security information from the user. Make it unobtrusive as possible, but never hide it.

Re:Phishers Rejoice! (1)

Atriqus (826899) | about 6 years ago | (#24740595)

The rejoicing happens on a daily basis considering unencrypted connections are business-as-usual. Slap on a bunch of warm, fuzzy-feeling shield badges and people can't turn over their info fast enough to you.

And TFA explains how it determines legitimacy; asking about it in the comments doesn't change that.

Re:Phishers Rejoice! (1)

Bill, Shooter of Bul (629286) | about 6 years ago | (#24740969)

No, it really doesn't explain how it determines if a self signed cert is legit. Just that they will be. Thats not enough information for me to trust this scheme. Luckily Firefox's behavior is default. So only proactive idiots would install this extension. The majority of lazy idiots will still be protected by fire fox. This won't save some poor guy's e-commerce site that uses a self signed cert and doesn't want the users to be warned.

band aids (3, Interesting)

jacquesm (154384) | about 6 years ago | (#24739563)

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 (2, Interesting)

Atriqus (826899) | about 6 years ago | (#24739971)

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:band aids (1)

swillden (191260) | about 6 years ago | (#24740791)

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.

You didn't RTFA. This plugin doesn't address certificates that have been erroneously issued at all. If the site presents a cert that validates back to a trusted root CA, is current, and contains the URL of the site that sent it, then Perspectives won't check anything.

Perspectives addresses a different issue: sites that use self-signed or expired certs. While you can certainly argue that the owners of those sites should get proper certs, for many of them it just doesn't make sense.

For example, I run a web and mail server used by my family. I apply SSL to the webmail interface, because I'd like it to be a little bit difficult for someone to snoop the passwords of my users when they log in. All of this is done on a very low budget, out of my home, so it doesn't make sense for me to shell out money every year to get a cert. So, I use a self-signed cert.

Unfortunately, this is vulnerable to a MITM attack. Does that make SSL worthless? Hell no. Mounting a MITM attack is significantly more difficult than just snooping an unencrypted password. Still, it's a concern.

Perspectives adds a way for the browser to automatically check two things about the self-signed cert:

First, that when a bunch of servers at MIT query the site for its cert, that they get the same cert that I get. So, if someone is conducting a MITM attack, they're spoofing not just my DNS, sitting in a coffee shop somewhere, but also MIT's DNS. Sure, that's doable, but it's significantly harder than just doing the MITM attack in the coffee shop. As more notaries are added, in different places around the world, the attack will get more and more difficult to carry off.

Second, Perspectives watches the cert over time, and will notice if a site that presented me one cert last week is presenting me a different cert today. If so, there's a chance I'm being attacked. Even if the attacker is spoofing the notary servers successfully, I'm still going to see a flag that the certificate changed. If this happens while sitting in a coffee shop, I'm probably going to decide that I shouldn't enter my password here.

Can Perspectives be defeated? Absolutely. That doesn't, however, make it useless.

Easy DoS Attack (4, Interesting)

plsuh (129598) | about 6 years ago | (#24739737)

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:Easy DoS Attack (1)

richardellisjr (584919) | about 6 years ago | (#24740537)

Your assuming the notaries would connect to the server for each initial connection by the users. More than likely I think they'd cache their results for a while as retrieving the same exact data (the digital signature) more than a certain number of times per minute would be wasteful.

Re:Easy DoS Attack (1)

ftobin (48814) | about 6 years ago | (#24741147)

I like your point about telnet. There is no doubt that the proliferation of ssh has helped security; many of rigid-hierarchy PKI supports seem to think that using telnet (HTTP) would be better than than using unsigned ssh keys (self-signed SSL certificates).

Re:Easy DoS Attack (1)

lubricated (49106) | about 6 years ago | (#24740543)

This has been beaten to death so many fucking times it's unreal. $15 per wireless router is too much. $15 per every computer that could serve out a web page is too much. Encryption should be default and obstacles to using it should be lowered so that no one has to ever use http. If ssh required some authority to sign every computer out there, we would still be using telnet.

Revamp the whole SSL thing (2, Informative)

ilovesymbian (1341639) | about 6 years ago | (#24739749)

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.

back and forth (2, Funny)

ILuvRamen (1026668) | about 6 years ago | (#24739763)

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"

DNS as a possible additional route of verification (1)

JSBiff (87824) | about 6 years ago | (#24740037)

      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 receiving from 'the server' really came from 'the server', or belongs to the owner of that DNS record. What if the owner of the server has uploaded the certificate into DNS, which the browser could also download a copy (or maybe a hash, instead of the full cert) of the certificate from the DNS record for that server, to try to check if they match?

      Now, there's at least one main problem I can think of with this - right now, DNS itself may not be trustworthy enough for this to work, as it is currently implemented. But, it seems to me we already need a more secure DNS system, because DNS is way too important to not be as secure as we can make it. If we're upgrading our DNS infrastructure, it would be an opportune time to add new features like this. I don't claim to be a security expert, so I don't know exactly how you would go about securing DNS, but as a start I would suggest this - most PKI systems are intended to avoid having a user need to receive and manually load a key from an off-the-net source. That's fine, as you don't want users to have to constantly have to do that for every new server they visit.

      But, would it be that onerous to have users enter or import a key, once, for their ISP's DNS server, which would act as a "Strong Link" in the web-of-trust - one very strongly verified key that can be used as the link with which you can 'complete' the chain of verified identities? Once the connection between a user and their ISP's DNS server is strongly verified, the ISP's can basically do the same thing with whoever their 'upstream' DNS provider is, be that a root tld server, or a higher-level 'backbone ISP'. All connections between DNS servers would be encrypted using these 'strongly verified' public keys.

      Now, I realize that for a given server, e.g. www.example.com, the 'root' servers don't know the IP address for the server 'www' in that domain - just the address for the 'example.com' DNS Server - but the root servers could then send either a fingerprint, or the public cert, back to your ISP's DNS server, so that when your DNS server contacts the example.com DNS Server, to retrieve the domain and cert info for the 'www.example.com' server, it can verify the identity of the example.com domain server.

      One 'convenience' related problem I can think of, at least, is users who move from one network to another - e.g. someone with a laptop or other wireless, mobile device who is using another network - at work, at a coffee shop, hotel, airport, etc. That could potentially be resolved by always using the same DNS server regardless of which network you are on, instead of the local network's DNS server. That is, regardless of which network you are on, you always get DNS from your ISP. This means taking DNS out of DHCP (that is, going back to statically assigned IP addresses for DNS), or, maybe, you use the local DNS server once, to lookup your ISP's DNS server (oh, but I hear you saying - if you use a different DNS server even once, just to try to lookup your home DNS server, there is an opportunity for an attack; my answer is, I think, not really - remember, your computer has locally stored the cert for your home DNS server, which you strongly verified, setting us that 'strong link' I mentioned earlier - any attempt at an attack would likely fail to authenticate against the locally stored certificate, wouldn't it, which could then cause your OS to trigger some sort of DNS verification error).

      Have I missed something stupid, or is there a reason a more secure DNS couldn't be built, and used as a trusted means of verifying DNS certs for other servers?

That's what certificates are for. (2, Insightful)

rew (6140) | about 6 years ago | (#24740049)

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.

Re:That's what certificates are for. (1)

cdrguru (88047) | about 6 years ago | (#24740885)

The problem isn't that www.yourbank.com is compromised. Nor is it an immediate problem that www.somecrook.com is issued a certificate for www.yourbank.com.

The problem is far closer to www.yourbanking.com being (a) allowed to exist and (b) issued a certificate for www.yourbanking.com saying all is legitimate. Everyone should know that if the two are held up against each other that www.yourbanking.com is a scam. Today, GoDaddy, Register.com and others will happily register the domain for you. I don't see it as a huge leap for these folks to get certificates either.

Doesn't replace need for signed cert (1)

DragonWriter (970822) | about 6 years ago | (#24740073)

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

This helps against some MitM attacks, but not against outright false-flag scams. Also, it provides limited help against MitM attacks where the "middle" is close enough to the other end that it is between all the notaries and the site to be verified. (Though monitoring certificates received over time may help with that in many cases.)

If this was offered as an add-on to the use of signed certs rather than a security alternative, it would be a good system.

Just an extra hoop? (2, Interesting)

k1e0x (1040314) | about 6 years ago | (#24740125)

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? (1)

Todd Knarr (15451) | about 6 years ago | (#24740409)

If I were designing it, the extension would have hard-coded into it a certificate that'd be used to sign all the notary SSL certificates. If a notary didn't present an SSL certificate signed by the hard-coded known certificate, it'd be rejected and considered immediate proof of an MitM attack.

MITM (1)

HTH NE1 (675604) | about 6 years ago | (#24740431)

So... to defeat a Man-in-the-Middle attack, you use another Man-in-the-Middle that you can trust?

Oblig. (0)

Anonymous Coward | about 6 years ago | (#24740479)

In Soviet Russia, Internet Eavesdropping Defeats YOU!

MITM attacks (1)

timbck2 (233967) | about 6 years ago | (#24740805)

I got your MITM attack right here [youtube.com] ! [youtube.com]

Tnew? (1)

ristonj (1195983) | about 6 years ago | (#24740813)

Can we tag this one tnew please? :-)

Still hackable, more difficult (2, Informative)

mathimus1863 (1120437) | about 6 years ago | (#24741011)

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

How about the extra traffic? (1)

felisconcolori (1191151) | about 6 years ago | (#24741035)

Assuming that the add-on becomes a very popular item, and that many people begin using it... how long before we see the following: 1) Poisoned Notaries - hackers setting up their own notaries and somehow inserting them into the system? 2) ISPs getting annoyed with the extra traffic and throttling back? Or ISP-level security appliances becoming suspicious that one GET begets many more connections? (Granted, I think this would have to be a very very well liked add-on, with huge user numbers and very large amounts of certificate checking.) 3) "Transparent" MitM attacks... The man in the middle being transparent to the flow of the certificate, but intercepting other portions of the document? (IANAC, so I have no idea how difficult or complex that may be to implement; I imagine a bit more than normal, as it's not the current topic.)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>