Hi Gerv, On 6/15/05, Gervase Markham <[EMAIL PROTECTED]> wrote: > Tyler Close wrote: > > No, it *is* entirely true, and it is a crucial point. > > > > The URL string displayed in the Location tool is the one sent by the > > attacker. > > ...from a domain over which the attacker has control. And if they have > control over www.bankofamerica.com, then we've lost anyway.
The phishing attacks that are currently plaguing the Internet don't direct users to www.bankofamerica.com. Control of www.bankofamerica.com is irrelevant. The attacker can choose another domain name for the URL and the current UI leaves it up to the user to detect the discrepancy. Depending on the cleverness of the attacker, this discrepancy may be arbitrarily hard to detect. I don't want to play these games with security. I just want to know if I'm looking at a page from my bank. As an interesting aside, www.bankofamerica.com isn't even the domain name that Bank of America actually uses for it's online banking. AFAICT, there is no rhyme or reason to what actual domain name any bank uses for a secure online transaction. Most use multiple different domain names. In these circumstances, claiming that the user should just know what domain name to expect and be able to reliably differentiate that domain name from all others is plainly ridiculous. The reality of phishing bears out this fact. > > If SSL is used, the displayed > > certificate is fetched from the attacker's web server. > > And, if the browser is not to put up nasty warnings, the SSL cert has to > be issued by a trusted CA. Those CAs who are trusted for ecommerce > should (although this is not the case currently for all of them) do > sufficient vetting that the attacker cannot put information misleading > to the user inside the certificate. As you say, this is not currently the case. It has never been the case. I bet it will never be the case. The CAs themselves have written white papers saying as much. Asking that only the virtuous and kind of heart ever get a trusted SSL cert is pie in the sky. No public CA accepts liability for how an issued cert is used. We need to design an anti-phishing tool for the web as it currently exists. Imagining a web with wide and stringent vetting, and corresponding liability, and then waiting for that to happen is just not practical. > >>The URL is sort of provided by the attacker, > >>but if the domain doesn't match the domain the user is looking for, they > >>can notice this using the domain indicator. > > > > That's exactly what I mean by: "asking the user to discover > > discrepancies in information that has been carefully designed for > > deception". The attacker can populate the Location tool and domain > > indicator with a deceptively similar domain name. > > How are you defining "deceptively"? That's a big part of the problem. We can't know what will be deceptive for any particular user. The user himself might not even be able to express it. Designing a global namespace in which no two names could possibly be confused by any user is an impossible task to define, let alone accomplish. IMO, private namespaces are the only feasible solution, hence the petname tool. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
