On 12/18/05, James A. Donald <[EMAIL PROTECTED]> wrote: > Even if the vendors do implement a policy that all new > urls must be significantly different from known high > value urls, which is not their stated policy, this is > not going to help much with such high value urls as: > "https://lb22.resources.hewitt.com" > > Proving true names is not much help, because there are > too many names.
Holy water indeed! As at least someone on this list doesn't seem to see that there is a 'too many true names' problem, here are some examples from the ssl sites I use (almost) daily. Second level domains changed to protect the guilty (and url's chopped for safety): 1) Bank number one: https://online.first-bank-of-lameness.com This looks ok at first, as the host name is always the same. However, if one goes right to this url by typing it in directly, you are directed back to www.first-bank-of-lameness.com, which is of course the perfect place to hijack things with a MITM attack. Also, the user visible url once logged in is always nice, short, and sweet, with all crypto-like parameters safely hidden from the users eyes in POST form parameters. 2) Bank number two: https://onlineeast3.the-other-lame-web-banking system.com/ This one may or may not have something different from onlineeast3, depending on, well, who can tell from where the user is sitting? But it also does not let one log in directly by typing in the url that is used in the secure part of the session, similarly to the normal merchant practice as poiinted out by [EMAIL PROTECTED] One would hope that the banks would close this hole for phishing, but alas in these cases, no. 3) Web mail number one: http://us.f509.mail.yahoo.com Of course trying to log into https://mail.yahoo.com gives a certificate error dialog box, although a user normally types in http://mail.yahoo.com for a 'normal' login. The ssl version of the same url redirects you to an https url that starts with something completely different. And while normall static for long periods, the f509 part merely indicates the mail store machine your box just coincidentally happens to be on. I have (once) seen that change for my account. When will that happen again, when they most my mailbox, or when I get subjected to a MITM attack? 4) https://mail.google.com also suffers from various "oh you typed in the https version of an otherwise valid hostname" certificate dialog boxes, but at least the hostnames don't change dynamically. Still cold comfort if I'm out in the wilds checking my mail from somewhere weird, as I don't carry the fingerprint of their genuine certs in my wallet or anything. Hm, maybe I should? I think that those examples pretty clearly demonstrate the limited value of any sort of 'true hostnames' in a web ssl context. Sorry for running off at the fingers without checking about this issue and ssh certs earlier, but these ssl examples are directly cut and pasted from live ssl sessions. What a mess, and again, holy water indeed! Ciao, -David Mercer Tucson, AZ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]