Recent Features
| |||||||||||||
Extended validation certificatesExtended validation certificatesPosted Nov 3, 2006 20:14 UTC (Fri) by pimlott (guest, #1535)In reply to: Extended validation certificates by bronson Parent article: Extended validation certificates
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.)
(Log in to post comments)
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.
|
|||||||||||||