Browser Extension Defeats Internet Eavesdropping

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

Comments

Excellent!!

[shaitand]

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

Re:Excellent!!

[Anonymous Coward]

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

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

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

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

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

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

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

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

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

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

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

Re:Excellent!!

[kestasjk]

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

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

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

Re:Excellent!!

[kestasjk]

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

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

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

Re:Excellent!!

[archatheist]

This is in the FAQ. From TFA:

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

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

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

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

Re:Excellent!!

[shaitand]

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

[shaitand]

Better yet, refer to this post.

http://slashdot.org/comments.pl?sid=656323&cid=24739889

Re:Excellent!!

[Anonymous Coward]

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

[nog_lorp]

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

[mccabem]

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

Thanks!
-Matt

Re:Excellent!!

[techno-vampire]

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.

Re:Excellent!!

[Anonymous Coward]

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

[Adrian Lopez]

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

[ksd1337]

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

Re:Excellent!!

[Anonymous Coward]

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

Re:Excellent!!

[Anonymous Coward]

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.

Re:Excellent!!

[JesseMcDonald]

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

There is no "Certificate Authority" transaction. The CA signature on the site certification is verified locally against a whitelist of CA public keys built into the web browser. The fact that anyone can create their own self-signed key for any domain is exactly why such keys do not establish identity, making MITM attacks possible. By contrast, CA-signed certificates can't be forged without first breaking (or otherwise acquiring) an established CA's signing key.

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

Re:Excellent!!

[CodeBuster]

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

Re:Excellent!!

[slashname3]

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

[camperdave]

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

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

Re:Excellent!!

[camperdave]

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

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

Re:Excellent!!

[shaitand]

'You are still completely missing the point here.'

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

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

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

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

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

Re:Excellent!!

[hal9000(jr)]

Read this then come back and re-think your response.

Re:Excellent!!

[shaitand]

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

No, it does not remove the theoretical possibility but it does remove the practical possibility.

The other method fails in both theory and practice because the security relies on the assumption of trust and that is not a sound principle in theory and is definitely not been shown to be sound in practice.

Re:Excellent!!

[Anonymous Coward]

If all traffic goes through NAP or something like that (some company's network,students' dormant). Can that be that one choke point? (I'm realy asking)

my english is perfect

Re:Excellent!!

[DragonWriter]

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

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

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

Re:Excellent!!

[sofla]

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

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

Re:Excellent!!

[caluml]

http://dictionary.reference.com/search?q=moot

Re:Excellent!!

[techno-vampire]

Exactly. Let's say you're a student, living in a dorm and using the school's broadband. All traffic in or out goes through the institution's LAN. If somebody in the school's admin wanted to run a MiTM attack for some reason, they'd control all access you had to the Outside World and could spoof the replies from the various notaries to make them fit the fake cert. Or, for that matter, let's say that the LAN goes out over a T1. Somebody at the other end of the pipe could do the same thing. Once the requests go out over different paths, however, it's much, much harder for any one person to control the responses.

Re:Excellent!!

[nog_lorp]

Thanks for the clarification. Wikipedia appears incorrect on this matter (http://en.wikipedia.org/wiki/Transport_Layer_Security#How_it_works), if you wanna fix it to be more clear.

Re:Excellent!!

[mrsbrisby]

By contrast, CA-signed certificates can't be forged without first breaking (or otherwise acquiring) an established CA's signing key.

Someone ought to tell Verisign that.

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.

No, they don't.

It guarantees it using a very narrow definition of guarantee that is orthogonal to reality: The point of a CA is that if the user trusts Verisign's judgement, and Verisign says they trust eaeaea1234 is "Microsoft Corp", then the user can decide whether they can chose to decide whether they trust "Microsoft Corp" or not.

That means trusting "Microsoft Corp"'s judgement, and their track record with keeping things secure. It also means trusting Verisign's judgement, and their track record with keeping things secure.

If "Microsoft Corp" isn't Microsoft Corportation, or Microsoft Corporation cannot keep their keys safe, then the certificate adds no security whatsoever.

If you (the user) cannot trust Verisign to handle that verification process completely, then the act of having a CA adds no security at all.

Moreover: Because users are being told (by people "good at computers" like you, no doubt) that CA certificates make them secure, they believe as long as it says "Microsoft Corp", that their information is safe.

Please stop perpetuating myths about SSL. It's broken. It's been broken for a long time.

Re:Excellent!!

[mrsbrisby]

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

You mean, like taking over the destination? Or their ISP? Or maybe their upstream?

Seriously.

It's not like that never happens.

Re:Excellent!!

[JesseMcDonald]

It's not really incorrect. The client can optionally contact the CA for additional validation; this is typically done to determine if the certificate has been revoked since it was originally issued. The certificate itself still has to be signed by a trusted CA, as indicated by the second bullet point under the Security section:

The client verifies that the issuing CA is on its list of trusted CAs.

Re:Excellent!!

[camperdave]

Read this then come back and re-think your response.

Self-signed certificates are perfectly valid and trustworthy provided that you can validate the self-signed certificate before trusting it. You do that by getting a copy of the self-signed certificate through some trusted method and then when presented with the self-signed certificate through SSL/TLS, you manually validate it with the copy you have.

So... yes I can.

Re:Excellent!!

[JesseMcDonald]

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

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

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

Re:Excellent!!

[geminidomino]

Exactly, and what kind of chief of security would I be if I let someone like me know things that I'm not supposed to know?

I try not to get too involved in my own life.

Re:Excellent!!

[Tom]

AFAIGT (as far as I get it) - the idea is that if all notaries show the certificate changed on the same day, it's likely it was a renewal or actual change. If some show a change, or all do but on different dates, then something fishy is going on.

Re:Excellent!!

[DragonWriter]

AFAIGT (as far as I get it) - the idea is that if all notaries show the certificate changed on the same day, it's likely it was a renewal or actual change. If some show a change, or all do but on different dates, then something fishy is going on.

But then, a MITM close (by network topology) to the server may succeed rather easily, since it will be appear to a change on the same date.

Re:Excellent!!

[Anonymous Coward]

You focus on Identity, and that at the cover of the certificate, this is nonsense, life does not work this way. The purpose, really of ether (a) two verifiable certificates, or (b) one certificate and a countersignature is to protect the channel from snooping ... replay ... once this is up the app can do anything it likes, over the secure channel, to confirm identity and trip impersonators, can also deal with duress an other oob messages.

Eg, after SSL

challenge 12 34 56 response AB 12 QZ 24, eg UBS e-banking

Father's Place of Birth? Kroc (duress Dublin)

The point is that once you have a secure channel you can establish identity easily ... and even a half secure channel lets you do useful work,

So your analysis is __dead_wrong__ !!!

Re:Excellent!!

[complete loony]

We already have a viable alternative to allow a kind of self signing with DNSSEC. DNSSEC requires a PKI infrastructure to be built into the DNS naming system that could make any other PKI infrastructure obsolete (see RFC-4398).

Re:Excellent!!

[Anonymous Coward]

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.

What makes you think it isn't?

A client can automatically make a secure connection to one of several publicly available "network notary servers" located around the world. These servers tell the client:

      1. What key does the server see for host.domain.com right now?
      2. What keys has the server seen in the past for host.domain.com ?

[Perspectives homepage]

Re:Excellent!!

[Culture20]

could spoof the replies from the various notaries to make them fit the fake cert

Presumably the notaries would have known certs embedded in the popular browsers. It doesn't prevent an evil ISP from spoofing it's customers' servers' certs via all incoming traffic though. Still need CAs.

Re:Excellent!!

[QuoteMstr]

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

Re:Excellent!!

[Anonymous Coward]

If the notary certificates are installed in the browser by default, they can be self-signed.

Re:Excellent!!

[ericfitz]

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?

Why wouldn't the web site use their existing private key to perform an authenticated update the notary's records shortly before expiration, or issue themselves a new certificate using the same private key, etc., rather than generating a new private key and a new certificate?

In this case the web site would use their existing identity to bootstrap their new one. This is how renewal works in the hierarchical CA world.

Re:Excellent!!

[shaitand]

'And as for being for-profit: unfortunately, money changing hands is by far the best authenticators available today.'

That keeps kids out of the game. There are businesses making millions in this and they can and will pay for certs.

'this "technology" (how I loathe that word) is still vulnerable to MitM attacks'

biased and for-profit are synonymous. Every for-profit entity is biased toward their own bottom line.

'If you don't like one CA, see another.'

And that assures me of that SOMEONE ELSE is who they claim they are?

'this "technology" (how I loathe that word) is still vulnerable to MitM attacks'

And those claims have been disputed elsewhere as well. While a MitM attack remains possible in theory, it does not remain possible in practice. This still provides a better level of assurance than the current system.

Re:Excellent!!

[mrsbrisby]

A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.

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.

You don't think that sounds like a mighty big if?

Who exactly do you think is worthy of that trust?

You aren't going to find absolute security anywhere.

Are you trying to indicate that bad security is better than no security?

There is always the possibility that someone, somewhere, may fail to uphold their part of the protocol.

This isn't some abstract possibility we're talking about.

TLS/SSL is still a significant improvement over systems without certificates or CAs, which would be insecure even if perfectly implemented.

I disagree. As it stands, TLS/SSL lulls users into a sense of security that is not provided or deserved. The user doesn't know if their data is safe, and the fact is TLS doesn't make any guarantees that the data is safe.

I think users should be scared shitless by any web site that asks them to enter any personal information- browser-padlock or not.

Re:Excellent!!

[JesseMcDonald]

Who exactly do you think is worthy of that trust?

Absolutely? No one. Good enough, most of the time? All of the ordinary certificate authorities.

This isn't some abstract possibility we're talking about.

It also isn't the massive breach you're trying to present it as. The fact is that a limited number of certificates were issued with names similar (but not exactly equal) to the names of well-known corporations due to insufficient validation by Verisign. This had no effect on the certification of the vast majority of web sites, and revocation procedures were already in place to deal with it.

The user doesn't know if their data is safe, and the fact is TLS doesn't make any guarantees that the data is safe.

TLS isn't designed to make such a guarantee. It's only designed to make it much more difficult to pass oneself off as a trusted organization, or to intercept the data in transit, and it carries out these functions quite well. Paranoid individuals such as yourself can feel free not to trust it, despite the minimal risk, and deny yourselves the benefit of reasonably-secure, reasonably-authenticated online communication.

The risk that the other party may not adequately protect the information once received is not specific to TSL/SSL. It applies whenever you give someone else data you would prefer to be kept private, online or offline.

Just out of curiosity, do you do the same thing offline? Do you insist on personally running FBI criminal background checks on your bank teller, for example? Or your broker? Or your employer's payroll department? Do you require proof of identity from the cashiers at your local grocery store? These individuals deal with sensitive information all the time, but you inevitably trust a third party to ensure the security of your personal data in these instances. An online transaction with TLS/SSL is far more secure from eavesdropping, and permits much more limited human access to your data. The risk that the system may fail you in any given circumstance is almost always much less than the benefit gained from trusting it. Unless your situation is very unusual -- or your risk tolerance absurdly low -- it makes sense to trust TLS for authentication rather than go without.

Re:Excellent!!

[DragonWriter]

Why wouldn't the web site use their existing private key to perform an authenticated update the notary's records shortly before expiration

Because the whole idea is that the web sites never initiate contact with notaries; the notaries check the web sites current credentials on client demand and store history.

Re:Excellent!!

[Anonymous Coward]

Authorities are able to seize a CA from a CA provider whereas authorities are unable to seize a CA from a notary. At least, the latter is true in my country.

Re:Excellent!!

[mrsbrisby]

Absolutely? No one. Good enough, most of the time? All of the ordinary certificate authorities.

How do you trust someone "most of the time"?

Is that, most of the time you're entering private and personal information? Or most of the time that you're browsing the web?

The threat that the efforts of these ordinary certificate authorities protect against is almost non-existent, and yet the threats that they don't protect against are significant.

Packet sniffing credit cards and passwords is actually extremely uncommon these days. Many sites route-filter, and these protections could be obtained in other ways.

SSL is expressly designed to provide identification information, and because they don't do this, and because there are SSL providers that sign for 30$, SSL doesn't provide any realistic measure of security.

It also isn't the massive breach you're trying to present it as.

Certificate authorities aren't the panacea that you're trying to present it as.

revocation procedures were already in place to deal with it.

No they weren't.

Windows almost never reloads the CRLs for code-signing, and there's no distribution network for delivering them.

It's only designed to make it much more difficult to pass oneself off as a trusted organization,

Apparently it fails at that too.

In any event, the problem is that SSL makes people believe it's secure. You even misspoke earlier when you said:

A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.

We know this isn't true. You meant to say it provides guarantees that it only be decrypted by the specified recipient, which is an entirely different thing.

Identifying who is being specified, versus who is being intended is a muddled area that negates the minimal security benefits SSL actually provides.

Just out of curiosity, do you do the same thing offline?

Do what thing?

The fact is that phishing websites, and asp/php worms are far more common than a waitress stealing my credit card.

Furthermore, if she steals my credit card, it is more likely she will be caught, than the operators of those phishing websites.

So why exactly do you think I need to require the same burdens offline that I do online?

Re:Excellent!!

[JesseMcDonald]

You are attempting to argue that TLS/SSL is useless unless it can provide absolute security. You are demanding the impossible. In the real world there is value in reducing uncertainty and risk even if they cannot be completely eliminated. The use of CAs reduces uncertainty compared to the same communication without them. For most people, under most circumstances, this is sufficient; the benefit gained from the communication outweighs the remaining risk. This is not a false sense of security; it is a realistic sense of security. You are demanding an unrealistic degree of security which no system can provide, online or offline. That is your prerogative, but it does not represent a fault in the TLS/SSL protocol or in the choices others make to trust it based on their own preferences and risk tolerance.

Re:Excellent!!

[Burz]

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

You miss the point of web certificates. They do not verify a person or corporation's existence (a silly goal), they verify an address.

I don't want web certs to certify birth certificates, corporate charters, or how nice/bad some authority thinks the site operators are.

I need to know the 'rentalgeek.com' my computer is currently talking with is the same site that got registered by whoever the rightful owners are. THAT is the only identity which can be readily verified start-to-finish over the Internet. I need to know the address hasn't been hijacked by a group that didn't register the domain.

Now whether 'ba.com' belongs to Bank Of America or the Boomerang Association or Ben Affleck is entirely up to me, the user, to determine through inputs I receive from web searches, yellow pages, snailmail correspondence, billboards, and links on sites that I reasonably trust. THERE IS NO WAY AROUND THIS.

Re:Excellent!!

[SimonBelmont]

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.

Identity is not provable? Depends on your definition of identity, I guess. I would say that identity is provable, at least in that, if I am given a public key when I walk into a bank to open an account, I can verify that the website I communicate with later is in fact owned by the same people I interacted with at the physical branch, which is all I care about. This is much better than the current certificate authority situation, in which I have to trust that a third party did their due diligence and are in fact certifying the people I think they are (and there have been cases where they are not, i.e. a phisher registers a legitimate-looking domain and gets a cert). The problems with identity these days is that it is too often based on poorly secured tokens, and too infrequently on identity established by face to face interaction.

Re:Excellent!!

[mrsbrisby]

You are attempting to argue that TLS/SSL is useless unless it can provide absolute security.

Balderdash. I'm arguing that you shouldn't say shit like this:

A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient.

Stop it.

The use of CAs reduces uncertainty compared to the same communication without them.

It reduces uncertainty marginally. If users knew just how marginal the security afforded by TLS/SSL, they wouldn't be so quick to enter their personal details. I suspect you probably know this.

You'll check again, and I said nothing about absolute security: I'm saying it's about as safe entering your credit-card in the clear as it is using an SSL/TLS encrypted channel. This perhaps wasn't true when SSL was first introduced, but it's true now.

That means you're arguing some false security is better than no security. Even if it costs a lot of cpu-time, makes it easy for people to DoS your server, slows down your connection, and gives money to people who don't deserve it.

That is your prerogative, but I'll still call you total cock-for-brains stupid, and encourage people not to listen to you.

Good Start....

[jeffy210]

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

[3p1ph4ny]

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

Re:Good Start....

[Mierdaan]

From the project's website:

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

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

Re:Good Start....

[Anonymous Coward]

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

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

They do.

Re:Good Start....

[funnyguy]

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

[funnyguy]

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

[jacquesm]

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

Re:Good Start....

[funnyguy]

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

[Mierdaan]

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

[Crazy Taco]

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

Somehow I doubt this. Or I should say, I doubt this will be extensive or practical enough to be useful for the following reasons:

1. How can keep a record of all the keys used by different services? I understand that storage is increasing, but there are potentially billions of websites. How are you going to keep track of all those keys?
2. And continuing along that line, how do you keep track of those billions (or at the very least many millions) of keys over time? Are you going to remember them all for years, or is there going to be a 30 day cache or something? That seems more likely, but far less useful since uncommon sites won't be cached, and the man in the middle could then succeed in compromising all paths to the destination.
3. What is the mechanism for key revocations for all these notaries?

I personally think a combination of a good certificates process, PKI and encryption is still the best answer to all these problems. If those systems are perfected, man in the middle attacks can't succeed. I know there are problems with getting these to be used in a wide scale manner, but they are some of the same problems that this notary system seems to suffer from (that I listed above), so I'm not really sure what we gain here except additional complexity. Not saying the notary system is a bad idea, but I'm not sure how you implement it in a practical manner without solving the problems that led to the need of this process in the first place.

Openning a New avenue of attack?

[Anonymous Coward]

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

[Meneth]

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

Re:Only obfuscation

[Rashkae]

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

Re:Only obfuscation

[Sir_Real]

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

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

Re:Only obfuscation

[denis-The-menace]

Where are my mod points when I need them!

Re:Only obfuscation

[fatboy]

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

[Rashkae]

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

[Rashkae]

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

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

Re:Only obfuscation

[Anonymous Coward]

Perhaps you should read the article though before posting.

You must be new here.

Re:Only obfuscation

[fatboy]

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

[Qzukk]

the certificate will not validate

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

Re:Only obfuscation

[Sancho]

There's another way that this can fail. Here's a hint: the URL to install the Perspectives plugin is http://www.cs.cmu.edu/~perspectives/Perspectives.xpi

Re:Only obfuscation

[RiotingPacifist]

youve just made the attack a lot harder, this is fail in the same way that a thief can still steal stuff from your house after you've locked your door. Sure its not perfect, but as long as it doesn't sell itself as such, this is a definite improvement

Re:Only obfuscation

[blincoln]

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.

I could also see it being used to detect if your employer is using a "transparent" SSL-inspecting proxy/gateway to monitor your "secure" internet traffic.

All of the major content-filtering/security vendors (Secure Computing, IronPort, etc.) have MitM-style components now. Because they depend on the employer installing a trusted root cert on all internal systems that use the gateway/proxy, normally they would not be detected unless someone were to look at the details of the certs their browser was receiving.

I have a nagging suspicion that something really bad is going to result. In the meantime, I'd at least like the padlock symbol in Firefox to be a different colour to indicate that my "secure" traffic is being monitored, so I can choose whether or not to continue.

Re:Only obfuscation

[Anonymous Coward]

if your employer is using a "transparent" SSL-inspecting proxy/gateway to monitor your "secure" internet traffic.

Not just your employer. I recently installed an AT&T DSL modem/router at a client, and the install disc to set up the modem had a screen that told me that I must accept a special root certificate on the next screen in order to configure the router/modem. I said no (thanks UAC!), continued anyway, and finished the setup without any problems.

I never heard back from those clients with any internet problems, so I'm not sure if the client is just hitting "OK" on the certificate warnings and not telling me, or maybe AT&T really has no such nefarious plans.

Beware!

[RevVoice]

They have spytech! THEY KNOW!!!

Does not work if comprimised on site side

[TorKlingberg]

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

Re:Does not work if comprimised on site side

[angio]

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

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

    -Dave (one of the researchers on the project)

Re:Does not work if comprimised on site side

[Tom]

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

[spotter]

this is probably a stupid question.

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

In the latter, doesn't this just add an additional burden to MITM attacking the notaries (i.e. intercept the request to the notaries and return a hunky dory a-o-k message). Don't attack the notaries, just prevent the message from ever reaching them. This can be solved with ssl, but then you've just moved the need for ssl to a different location.

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

Re:Does not work if comprimised on site side

[lubricated]

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

Re:Does not work if comprimised on site side

[angio]

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

[nahdude812]

If a site legitimately has their key compromised (or they just for some reason need or want to change their key), how do they change it to something new and secure without that appearing to be a mitm until it's been there long enough that Perspectives accepts it?

Re:Does not work if comprimised on site side

[John Hasler]

Then it isn't a mitm attack, is it? They don't claim to defend against every conceivable attack.

Re:Does not work if comprimised on site side

[TorKlingberg]

I think the idea is that the browser can ship with ssl certificates for the notaries.

Re:Does not work if comprimised on site side

[sy5t3m]

Given that an attacker capable of hijacking all traffic to an MX server for even a short amount of time (say 30 minutes or less) can obtain a CA signed certificate and completely override any objections from firefox, Perspectives packing in after a few days is still an improvement.

Re:Does not work if comprimised on site side

[lubricated]

First time I get to say "WOOOOOSHHHHH!!!"

Do I get a prize?
I don't blame you though. That may have been to subtle for some.

What about signing?

[v1]

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?

[Free the Cowards]

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?

[robo_mojo]

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?

[TopSpin]

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.

Re:What about signing?

[ultranova]

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

Actually it's very simple: have every domain name come with a certificate, signed by the domain provider (chaining all the way up to the root name servers) and good for signing any subdomain/machine in the domain. Problem solved.

But of course if you do that, then Verisign is going to go "WAAA ! We're losing profits !", so it won't happen.

Re:What about signing?

[zippthorne]

...encryption doesn't necessarily need identity; encryption is useful independently, regardless of what the security zealots claim.

When?

Or did you really mean that

...encryption doesn't necessarily need identity; encryption is useful independently, as long as identity is verified independently, too

Now all ...

[SlashDev]

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

Re:Now all ...

[Atriqus]

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

But who trusts their notaries?

[querist]

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

Who picks these people/companies?

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

Disclaimer: I am a SC Notary Public.

Re:But who trusts their notaries?

[ccguy]

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

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

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

Who picks these people/companies?

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

I think this a promising idea.

Re:But who trusts their notaries?

[Tom]

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

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

Re:But who trusts their notaries?

[Anonymous Coward]

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

Nope.

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

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

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

Re:But who trusts their notaries?

[Andrzej Sawicki]

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?

[redbu11]

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

Re:But who trusts their notaries?

[Deadplant]

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?

[ccguy]

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.

OK, so you go to the DMV or wherever IDs are issued in your country and get one. Then you show it to someone in the street and ask for a description of that ID.

Do the DMV and the guy in the street have the same role? One is issuing the ID (and making sure they give it to the right person) and the other is just looking at an ID someone else issued. The person in the street is not even checking if the guy in the picture is the same as the guy holding the ID.

If needed, I could try harder and use a proper car analogy.

Re:But who trusts their notaries?

[skeeto]

"But who trusts the trustmen?"

Err... nevermind.

Re:But who trusts their notaries?

[bhtooefr]

Not easy to set up a bad notary that works for spoofing a site, but very easy to set up a bad notary that works for a DoS attack.

Re:But who trusts their notaries?

[Anonymous Coward]

Simple.

A self-signed certificate would be the same as a self-issued public key. The problem is simple: if you don't already know the site you got that cert/key from IS the real site, you have no way of knowing if the cert itself real. If you already know the site is real, then you don't need the cert in the first place for verifying the site is real.

To put it another way, a self-signed cert or self-issued public key can NEVER be trusted as a method of Authentication, only as a means of Encrypting the transfer.

Despite the whining I've heard about Firefox 3, they are correct: a self-signed cert is not valid to identify whether the site you are talking to is real or not, it only protects the data transfer between you and whatever site you are actually talking to.

In the end, the only way to be really sure that the site is real, is to have them send a copy of their cert or public key to you via a secure transport method, like the post office or a courier. Of course someone could kill the courier or hijack the local post office but that's a lot less likely than someone trying to tamper with a data transfer over the internet.

So to sum it up, the issue is not whether you use certificates, PGP keys, etc., the issue is whether or not the key, etc. you received came from who you thought it did. Even with a 3-way authentication method there is still the possibility of someone performing a man-in-the-middle attack where the real key is intercepted and replaced with a bogus one.

Re:But who trusts their notaries?

[Tom]

No, you're not, and this is a possible attack.

However, technically speaking, even in that case the system works as advertised, because what it says is basically "I got conflicting answers, something is wrong here" - and that's true, even in your case, something is wrong. Finding out what is a whole different beast.

Re:But who trusts their notaries?

[Anonymous Coward]

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.

Actually, there's no reason why you can't eliminate single point of failure from the CA model, either. All you need to do is set up a system where certificates can be signed by multiple CAs. Then your browser has a rule that it will only trust a certificate authenticated by X of Y CAs, or at least one CA from multiple sets, etc.

The reason I don't like this notary idea is that it provides a rather weak level of assurance. Assuming the CAs aren't compromised (which I think is reasonable for most situations), the mathematics of public key cryptography provides a much higher and well-defined level of assurance than this model.

Now, you might be able to fix that objection if you could provide the certificates securely to the notary, but then are you really providing any more security than what the CA is supposed to be providing?

Re:But who trusts their notaries?

[Anonymous Coward]

And if you ain't with it, you're in the food chain.

Re:But who trusts their notaries?

[Anonymous Coward]

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 all fine and dandy, unless I've compromised a server between your computer and the internet. Now you have a 0% chance of having ANY trusted sources, even if you have 1 billion trusted servers- because I can hijack every attempt you make to authenticate with a different 'notary' or 'cert authority'.

This is the root problem with authentication- it is always vulnerable unless you have some type of pre-shared key that was delivered by a Known good source. In the case above, any internet-based source is potentially suspect with the existing systems.

Re:But who trusts their notaries?

[Anonymous Coward]

The idea of "notaries" is essentially the same idea as having the Certificate Authorities: a third party who is considered trustworth(y) 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.

Whether they technically are "signing" something isn't relevant. They are "vouching" for another's identity. In Public Key Crypto, there are 2 and only 2 schemes: hierarchical (where there are some sort of organized central authorities) Public Key Infrastructure (PKI) and Ad-Hoc (i.e. PGP's web of trust). This falls into category #1. There is an organization to it (notary servers and principals that need validating). There is a sense of centrality (notaries), even if there are "thousands" of them. A web of trust would be a neat idea, but it would require changes to the x509 spec (more like a replacement spec), because multiple digital signatures (vouching or validating in the notary model) is not possible without being within a chain (direct hierarchical relationship).

In short, this is Public Key Infrastructure with worse applied crypto.

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.

Not important? What if you pick all of the pwned ones? How important is it then, when you get all fake/phished answers?

What I don't understand in all of this debate of FF3's handling of certs is, Why don't the complainers just import self-signed certs and call it done? Or if they really feel like SSL certs should be free (and why not, it's not like Verisign and both of its forgotten underdog competitors did a good job identifying identities until recently with their EV-SSL certs-- and at the cost of another 20% price hike for their customers), then why not just use a free CA or create another free CA if they don't like what's out there? Start a movement, get Mozilla to include the CA cert in the list of CAs in the future. Stop whining.

Yea, that, or SITES CAN UPDATE THEIR CERTS!

[HaeMaker]

Stupid solution for a stupid problem.

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

[Anonymous Coward]

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!

[Anonymous Coward]

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.

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

[Anonymous Coward]

If the only place you're accessing your firewall is from your home network, consisting of your PC plugged into your firewall, then you don't care about HTTPS in the first place.

Otherwise, there are plenty of networks on which the notary strategy would work great with embedded devices, by having a notary on that network. Not to mention all the embedded devices (home server appliances, for example) that are directly visible on the internet.

Nothing to do with Firefox's nonsense.

[argent]

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.

[schwaang]

From TFA:

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

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

Re:Nothing to do with Firefox's nonsense.

[argent]

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.

[Korin43]

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.

[Hyppy]

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.

Re:Nothing to do with Firefox's nonsense.

[schwaang]

But there are legitimate uses for self-signed certs IMHO (intranets, privacy for non-commercial sites, embedded devices, etc.). Having to set up your own CA or kow-tow to Verisign or GoDaddy shouldn't be necessary for every minor use of ssl.

I think you're right that any browser would have to give _some_ kind of warning for a self-signed cert it hasn't seen before. It's just that a lot of people think that FF3's handling of self-signed certs is an over-the-top reaction to the very real threat of phishing, resulting in too many hoops to jump through for the legitimate cases.

Myself, I agree with the OP's point on that one, FF3 should probably be tweaked to not go DEFCON 5 over every self-signed cert, even if Perspectives can work around the issue.

Re:Nothing to do with Firefox's nonsense.

[argent]

Self-signed certificates are a security risk to virtually any normal user.

That's the conventional wisdom, and yet all SSH keys are self-signed, and MiTM attacks on SSH are really obvious.

The major security risk from self-signed certificates is a result of designing SSL to make self-signed certificates risky.

Too much centralized trust

[Animats]

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

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

Re:Too much centralized trust

[Tom]

Not true.

Google for "Credence", that's a trust system developed specifically for situations where your "web of trust" can be assumed to be under attack (torrent ratings, we know the music and movie industry employ companies to seed crap and rate it up, while rating down actual releases).

It would be possible to adapt Credence to this situation, or come up with something similar.

Some many reasons this is a bad idea:

[keithadler]

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

Re:Some many reasons this is a bad idea:

[Anonymous Coward]

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:

[Anonymous Coward]

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:

[Anonymous Coward]

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

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

Re:Some many reasons this is a bad idea:

[Anonymous Coward]

Tier 1 Notaries:

NotaryOne.com funded by CapitalOne and BankOne
Notarisa.com funded by Visa
CitiNote.com funded by Citibank
notary.amazon.com
NotaryPal.com bought out by Ebay

It would cost next to nothing to run notaries, and would be very much in the interests of many big money corps to fund Tier 1 notaries. And there is absolutley no liability (unlike running a CA).

Re:Some many reasons this is a bad idea:

[Anonymous Coward]

1. Bringing down notaries would bring down all SSL/TLS traffic

Not really, it would only delay it before the extension says "Unable to verify cert with notary. Continue?"

2. Compromising the extension itself could allow for proxying of SSL traffic; exposing private information

Yeah, and if you run a virus on your machine bad stuff can happen.

3. Using the the notaries increases the footprint of SSL traffic; increasing the attack surface

I fail to see how a simple "I got this cert for this site, is that correct?" query can "increase the attack surface".
It's PKI, passing the *public* key to the notary isn't going to help a would-be attacker very much.

Phishers Rejoice!

[Anonymous Coward]

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

[Atriqus]

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!

[Bill, Shooter of Bul]

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

[jacquesm]

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

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

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

Re:band aids

[Atriqus]

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

Re:band aids

[swillden]

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.

Re:band aids

[Anonymous Coward]

I want to be a notary! I'm sure there is something nefarious I could do with a list of all the encrypted URLs you are visiting, especially if I can convince you to install my browser plugin.

Is this whole scheme about social engineering on a grand scale in the open? How do you know? Trust is a funny thing.

Easy DoS Attack

[plsuh]

Folks,

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

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

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

--Paul

Re:Easy DoS Attack

[richardellisjr]

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

[lubricated]

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.

Re:Easy DoS Attack

[ftobin]

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

[Eighty7]

If ssh required some authority to sign every computer out there, we would still be using telnet.

That analogy is subtly wrong. Identity in SSH is built in, usually as passwords. What use is encryption if you don't know who you're talking to?

Re:Easy DoS Attack

[Anonymous Coward]

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

Re:Easy DoS Attack

[Anonymous Coward]

You really dont get it, do you

Re:Easy DoS Attack

[swilver]

You should perhaps spend a few years of your live pondering that question.

Re:Easy DoS Attack

[Anonymous Coward]

Passwords authenticate only the client, not the server.

Revamp the whole SSL thing

[ilovesymbian]

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

[ILuvRamen]

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

Re:back and forth

[ultranova]

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

But what if the attacker changes the roadsigns on the way, so that you end up at his MitM datacenter instead ?

Compromising a CA

[Beryllium Sphere(tm)]

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:Compromising a CA

[Anonymous Coward]

Which just might get zero access. You can be sure that someone who works there will see who is trying to buy them. If it were me, they would find the machines w/ the private key were blanked.

Re:Compromising a CA

[camperdave]

I figure organized crime can do it for a lot less. Guido and Nunzio can do a lot of "leveraging" for a mere hundred thousand.

Re:Compromising a CA

[John Hasler]

If Guido & Co could "leverage" big business they would have done so a long time ago. They're up to setting fire to drycleaning shops but they know enough to stay out of the big leagues.

Re:Compromising a CA

[camperdave]

I think you're myth-ing the point.

DNS as a possible additional route of verification

[JSBiff]

      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.

[rew]

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

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

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

Re:That's what certificates are for.

[cdrguru]

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

[DragonWriter]

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?

[k1e0x]

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

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

Re:Just an extra hoop?

[Todd Knarr]

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.

Re:Just an extra hoop?

[arkhan_jg]

Because there will be a lot of notaries. Sure, if someone's determined enough to spoof a large number of them through DNS, over a long enough period of time, he can break this.

The point is not that it's totally unbeatable, it clearly is, but it makes the work a MitM attacker has to do to spoof an important site that much greater. Security is layered, and about raising the bar for attacks to succeed.

Re:Just an extra hoop?

[zippthorne]

Easy: Just have the notaries register with Verisign.

MITM

[HTH NE1]

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

My ISP is the People's Republic of China

[davidwr]

I've been screwed since 1949.

Oblig.

[Anonymous Coward]

In Soviet Russia, Internet Eavesdropping Defeats YOU!

You want PKI without the I ?

[Anonymous Coward]

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

MITM attacks

[timbck2]

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

Tnew?

[ristonj]

Can we tag this one tnew please? :-)

Depends on where the MITM is.

[Ungrounded Lightning]

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

Still hackable, more difficult

[mathimus1863]

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

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

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

Re:Still hackable, more difficult

[rsborg]

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.

Couldn't this be resolved by each notary maintaining a certificate for SSL verification?

That would up the attack difficulty to be replicating separate secure connections to the various notaries.

How about the extra traffic?

[felisconcolori]

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

Combine with one-time passwords

[nowen]

This is similar to what we've done with WiKID (sourceforge.net). A hash of the server's cert is stored on the auth server and is sent down to the software token with the OTP. The token fetches the cert via the user's internet connection, hashes it and compare the two hashes. If it matches, the otp is presented and copied to the clipboard. and the default browser is launched to the website.

The key difference is that your server becomes the validation source and not a 3rd party.

Defeats Internet Eavesdropping?

[Valdrax]

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

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

Re:Defeats Internet Eavesdropping?

[arkhan_jg]

If you live in europe, the websites you visit are already being logged by your ISP, and available on demand by the government in most countries.

The sites you visit also keep logs. You think you've got much anonymity from the bank when you login to the bank website? They all keep detailed records for police and governments.

No individual notary would see much of a list of your site vists. All they'll get is that you visited your bank, or gmail, or wherever - the domain; the same information logged by your ISP.

A blackhat MitM attack would intercept your gmail login, or your bank login. They can read the details of your communication, and with that information go on to steal a lot of your money, or get you into debt in your name, or any of the other nasty things they do while pretending to be you.

The only time it'll make a difference is if you're already using a third party anonymising proxy - in which case, it's still not a bad idea to check that your proxy isn't pulling a fast one - after all, the notary will see one request from your new anonymous IP for that secure domain, which tells them pretty much diddly.

How is this news, anyway?

[Kvasio]

Opera has similar functionality for a few months now.

Re:How is this news, anyway?

[Ash-Fox]

Opera has similar functionality for a few months now.

But it doesn't work because barely anyone uses Opera.

One thing Moz did right in FF3. . .

[JSBiff]

Ok, the error message for self-signed certs is a bit overly-alarmist, but I like one thing FF3 does that previous versions didn't - local certificate caching. So, if I've accepted the cert once, it never has to retrieve the cert again, so there is only one opportunity for a MITM, not an opportunity every time I visit the site. If I got the right cert the first time, then I'm secured from that point forward, and never see the nag message again.

Fault Tolerance

[mr.witherspoone]

Sounds like we are going from the "Two generals problem" to the "Byzantine generals problem" (or more specifically the "Commander and Lieutenants" solution to that problem) the latter of which can let a certain amount of generals be compromised and still have the desired outcome. Hey, math wins again! Was Charlie involved?

Here's what "doing it right" would be...

[argent]

I like one thing FF3 does that previous versions didn't - local certificate caching.

That's how it should be done (and how I've been suggesting it for years), except it should be handled similarly to the way SSH does it. I think there's 6 cases to consider:

1. First time, if and only if you have not seen a certificate for that site before: "This is a self-signed certificate. Click here to accept it once, click here to accept it every time."

2. If a different self-signed certificate shows up, whether or not you selected 'accept it every time', "This certificate has changed. Someone may be attempting to trick you ... etc etc etc...".

3. If a CA-certified certificate shows up, and it had previously been self-signed, a similar warning, but less severe.

4. If a CA-signed certificate changes, tell the user that too, but informationally... not as a warning.

5. Don't notify for a new CA-signed certificate at all.

6. If a self-signed certificate shows up where a CA-signed certificate had previously shown up, THEN you pull out all the stops and require the folderol Firefox does right now. That's the case you REALLY have to watch for.

Who Notarizes the Notaries?

[Doc Ruby]

Maybe if the notaries were banks, or some other org that can pay damages when they enable some exploit to damage someone who trusts them, this system might be reliable. Because then the notaries' recommendation to trust the other site would actually have some consequences when they're inevitably wrong sometimes.

And if the transactions, with the questionable sites and the notaries themselves, were all recorded at yet another independent storage. Auditing those logs is the crux of any protection this system can offer.

Re:Who Notarizes the Notaries?

[angio]

Re: recording the transactions

The core perspectives design supports this; we're in the middle of implementing it. If you read the Perspectives paper (it's fairly readable for anyone with a moderate technical background), section 5 (Detecting Malicious Notaries) discusses exactly how you can have other notaries log the observations made by the rest of the network. It's on the list of things to add to the Firefox plugin for the next major version.

(I linked to the HTML version of the paper; the PDF version is prettier. :)

Moves it

[Joebert]

So what's to stop evesdroppers from setting up fake responders ?

Does this really fix anything, or does it just bring about a new round of hide the sausage ?

DNS Spoof For The Win

[Farmer Pete]

Sure, with this system you can't just DNS spoof the website you are trying to eavesdrop on like you've been able to in the past. However, why not DNS spoof both the website and the notary? When the client asks the Notary for verification, the Mitm responds to the client dns request, tells it that the Notary can be found by connecting to the MitM's hacked Notary server which verifies the hacked certificate as being legit. All this does is make a days worth of work for some hackers to program a fake Notary server...or better yet, they'll just hack the REAL notary server and swap some certificate records.

POS

[tarball]

Of course the best part is that it doesn't even prompt to install. And Mozilla doesn't recognize the extension.

Re:POS

[tarball]

And yes, I'm running version 3.

Whitelist?

[Anonymous Coward]

Default whitelist:

www.pncbank.com
cards.chase.com
www.aa.com
smtp.andrew.cmu.edu
www.citicards.com
mcp.microsoft.com
www.mealpayplus.com
www.pnc.com
www.onlinebanking.pnc.com
chaseonline.chase.com

Why have a default whitelist at all? Do they think these sites will never be compromised?

I hate to say it....

[Allnighterking]

But the whining about the new setup in Firefox is really nothing more than the same level of whining you get when Homer Simpson says "10 Seconds.... oooooh but I want it now." Decision time folks. Do you want a reasonable expectation of security or to be lazy? It must be understood that whatever automation does for you it also does to you. The end result is a layer on top of a layer that slows down the web (from the user viewpoint) even more. Despite what you have been told.
1. You are smarter than your computer. (all you need to be able to do is add 2 + 2, a computer can only do 1 + 1 + 1 + 1)
2. You are eventually, no matter how hard you try to avoid it, going to have to take responsibility for your own decisions. What you click on and the actions it results in are 1 of them. This includes deciding if you want to accept an SSL cert or not.

Response from Perspectives?

[slyborg]

+1

I was wondering about this myself. This seems like a glaring issue that essentially renders the idea worthless, even if the notaries are trustworthy.