security (was Re: [dix] Re: Gathering requirements for in-browserOpenID support)

[Alaric Dailey]

Ryan Barrett wrote:
> On Fri, 20 Oct 2006, Gabe Wachob wrote:
>
>   
>> Visa's 3-D Secure (known as Verified by Visa) does NOT trust DNS. In fact,
>>     
>
> fair enough. for closed systems, which it sounds like 3-D Secure is, that's
> definitely a luxury that may make sense. however...
>
>
>   
>> As a recent former employee of Visa, I can tell you that DNS is absolutely
>> *not* trusted for conducting value transactions on the net. At the very
>> least, SSL is the basis upon which any transaction data is trusted.
>>     
>
> i don't understand. DNS and SSL solve fundamentally different problems. DNS
> resolves domain names to IP addresses; SSL encrypts TCP network connections.
>
>   

SSL encrypts data, but its weakness is, that you can validate that the 
name in the certificate matches the name of the site you are at, NOT 
that you are at the right site.

You see, if someone poisons your DNS, then you end up at the wrong site, 
and with a carefully planned attack, a bad-guy could create a CA that 
calls itself Verisign. Now, even if the user gets an error from their 
browser, they will think its no big deal as most users don't know how to 
validate certs themselves.  Making this problem worse is the "click 
until the boxes get out of my way" mentality users have adopted, they 
don't read the message boxes.  Topping this off is self-signed certs 
setting off these messages like those from https://www.biglumber.com or 
the fact that MS hasn't bothered to get their new root certs in other 
browsers. 

SSL relies on DNS to validate the identity of the site.  Thus DNS solves 
a different problem, but it is intimately connected to SSL.  The only 
way to KNOW that the DNS hasn't been modified, is to use DNSSEC.

http://startssl.wordpress.com/2006/09/16/ssl-dns-poisoningpharming-phishing-and-dnssec/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061020/443b681b/attachment-0001.htm>