browser vendors and CAs agreeing on high-assurance certificates

[David Mercer]

On 12/18/05, James A. Donald <jamesd at echeque.com> 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 lynn at garlic.com.  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 majordomo at metzdowd.com