| |||||||||||||
Extended validation certificatesExtended validation certificatesPosted Nov 3, 2006 2:34 UTC (Fri) by pimlott (guest, #1535)In reply to: Extended validation certificates by iabervon Parent article: Extended validation certificates
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.
(Log in to post comments)
Extended validation certificates Posted Nov 3, 2006 19:20 UTC (Fri) by bronson (subscriber, #4806) [Link] 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] 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 (subscriber, #1954) [Link] 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] 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 (subscriber, #1954) [Link] 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.
|
|||||||||||||