Phishing, SSL, and WHOIS.

Via comp.risks: Netcraft: SSL’s Credibility as Phishing Defense Is Tested. The unsurprising news: SSL certificates (mostly) deal with domain names. Only that match can be verified by a web browser, and signalled by a closed pad-lock. The security is ultimately based on a match between a domain name and the “site” the user wants to visit — that is, “Amazon,” “Deutsche Bank,” “Earthlink,” “Microsoft,” “IBM”, as opposed to, e.g., “ibm.de” or maybe “ibm.com.” Linking the “site” (i.e., the user’s idea of who the merchant is) to a domain name is, realistically, left to trademark law and the UDRP. This doesn’t work for little-known marks. Less realistically, it is left to WHOIS, which, as many proponents of open access tell us ever again, is used by consumers to “verify” online merchants. This doesn’t work at all — most “ordinary” net users I know don’t even have an idea what WHOIS is, and then again, we all know the database is inaccurate, can’t be made accurate, and doesn’t even have the data elements you’d ask for. When consumers are confused about the domain name they are visiting — be it due to typo-squatting, be it due to cleverly crafted deceptive URLs –, though, SSL, WHOIS, trademarks, and all that stuff don’t even have a chance to help them. It’s this kind of confusion that the latest phising expeditions exploit.How do you fix this? Make sure users can’t easily ignore information about the merchant that’s behind a site. Display it in a state bar that can’t be scripted. And don’t take it from WHOIS, but take it from the SSL certificate.