Extended validation certificates

Posted Nov 2, 2006 14:44 UTC (Thu) by kleptog (subscriber, #1183)
Parent article: Extended validation certificates

I've occasionally wondered if it would be possible to build some kind of "web-of-trust" for certificates. We don't trust the issuer, but I'd probably trust certificates more if someone I know figured the cert was ok.

About the only good part about SSL certs is that they're tied to a domain name, so we should be able to build something on top of that...

to post comments

Web Of Trust

Posted Nov 2, 2006 15:08 UTC (Thu) by rfunk (subscriber, #4054) [Link] (1 responses)

http://www.cacert.org/

Web Of Trust

Posted Nov 2, 2006 15:20 UTC (Thu) by kleptog (subscriber, #1183) [Link]

That puts web of trust at the issuer end, but does nothing for users. For example, I might trust a CAcert certificate to be from who it says, but that doesn't stop the person being a phisher.

The PGP documentation goes on about the difference being trusting the certificate belongs to a particular person, and whether the person is trustworthy in general. It's the latter I want to deal with...

The things I'm thinking of are someone getting a certificate setting up a fake banking site. I would like something to say "this site is from who it says it is, but it's not trusted by other people (and in particular, not by your buddy X)".

Extended validation certificates

Posted Nov 2, 2006 23:15 UTC (Thu) by iabervon (subscriber, #722) [Link] (7 responses)

The solution for bank sites, at least, is to print the certificate fingerprint on bank statements and ATM cards. Of course, browsers would have to have an interface for users to indicate that they have personally validated the certificate for some particular purpose. If you're using an ATM card provided to you by an attacker, you've got problems already. And this is the only way to stop an attacker with a similarly-named legitimate business as a front (yes, this is a secure connection to a legitimate business's web site, but it's not my bank, so I shouldn't log in). For that matter, I know that there have been multiple legitimate financial institutions simultaneously using the name "Chart Bank"; hopefully, their employees are honorable enough to not take advantage of users who try to log into the wrong one, but who knows?

Extended validation certificates

Posted Nov 3, 2006 2:34 UTC (Fri) by pimlott (guest, #1535) [Link] (6 responses)

The solution for bank sites, at least, is to print the certificate fingerprint on bank statements and ATM cards.

That's absurd, as is the claim in the article that SSL is "meaningless for anything other than an indication that the traffic is encrypted". All the bank has to do is give me an https URL, and I type it in, and I can have quite high confidence I'm talking to my bank. It's not airtight: I could mis-type--though of course I only need to type it once, then bookmark it; and there have been incidents of registrars giving certs to non-owners of domains. But it's practical and I trust it with my finances.

Which is not to say that SSL as deployed today is a resounding success--far from it. But suggesting that the padlock is "meaningless" or that users should be checking fingerprints by eye is not productive. The scheme discussed in the article, on the other hand, may be. Let's take the time to look at it and find out.

Extended validation certificates

Posted Nov 3, 2006 19:20 UTC (Fri) by bronson (guest, #4806) [Link] (5 responses)

All the bank has to do is give me an https URL, and I type it in, and I can have quite high confidence I'm talking to my bank.

No you can't. DNS cache poisoning is still depressingly easy. And most packets hit 20-30 boxes as they transit the internet. All it takes is for one of those boxes to be subverted. All of these attacks rely on your typing the URL perfectly. Phishing is for chumps.

The only way you can be confident you're talking to your bank is to have an out-of-band fingerprint at each end. Each party must authenticate the other. SSL's one way "authentication" will always be prone to MITM attacks, always.

I've been meaning to write my SSL MITM proof of concept tool for three years now. That would demonstrate the problem to people who don't have crypto experience. Alas, the round tuits just aren't piling up.

Extended validation certificates

Posted Nov 3, 2006 20:14 UTC (Fri) by pimlott (guest, #1535) [Link] (4 responses)

How does DNS spoofing defeat certificate verification? Can you give me a concrete scenario that undermines my claim? Assume that I type carefully and double-check my spelling. (I do appreciate that typo-phishing is a serious vulnerability, though.)

Extended validation certificates

Posted Nov 4, 2006 1:14 UTC (Sat) by giraffedata (guest, #1954) [Link] (3 responses)

For those that don't catch what pimlott is implying: As part of https session negotiation, the server supplies its domain name and the browser verifies that it's the same name you typed into the browser. So DNS and IP routing find the server but don't establish its identity in any way.

Verisign supplies a certificate that's supposed to convince you that whoever is running the server that claims to be acme.com is the company named Acme. But even if you don't believe Verisign verified that, you probably believe that Verisign didn't hand out certificates for acme.com to two different people, and you know Acme Bank didn't publish that URL until it had a certificate for acme.com in hand.

Extended validation certificates

Posted Nov 4, 2006 13:13 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

Sure, but I can create a certificate on my computer for "acme.com". I can even copy all the details from the real certificate. If I then use DNS spoofing to get people to visit my site, the only way the user is going know the difference is the different fingerprint and the fact that it's not signed by the real verisign.

Most users won't distinguish this from a normal annual certificate change due to expiry.

I think it's the "each certificate has one issuer" that's the real problem here. I have to trust verisign to not give out bad certificate. But why couldn't the local banking regulatory authority also sign each bank's certificate, then I'd be trusting an institution I know (with a legal obligation to not screw up), not one on the other side of the world. Consumer organisations could do this also, then at least I'm placing my trust in something that I know, rather than a company trying to sell for the lowest price.

Extended validation certificates

Posted Nov 4, 2006 21:18 UTC (Sat) by giraffedata (guest, #1954) [Link] (1 responses)

the only way the user is going know the difference is the different fingerprint and the fact that it's not signed by the real verisign.

The fact that it's not signed by Verisign should be enough. That will cause the browser to pop up a message saying, "He says he's acme.com, but I have no proof of that. Do you believe him?" Anyone aware enough to check a fingerprint against something on his mailed statement would be aware enough to say, "no way" in this case.

Most users won't distinguish this from a normal annual certificate change due to expiry.

I never get anything like this, in the beginning or anually, from a website operated by a major company; I don't think others do either.

Now I don't doubt that millions of people will blow right past the warning from the browser, having no idea what it means. But all we're claiming in this thread is that a user can make the system work.

I have to trust Verisign to not give out a bad certificate

That's true, and is discussed in other threads here. But the level of trust you must have in Verisign is very, very small. Imagine the level of negligence or evil required of Verisign for it to sell an acme.com certificate when it has already sold one to someone else.

Extended validation certificates

Posted Nov 4, 2006 21:57 UTC (Sat) by pimlott (guest, #1535) [Link]

But all we're claiming in this thread is that a user can make the system work.

Thank you, giraffedata, for helping explain exactly what I meant.