On Friday 13 May 2005 17:51, Gervase Markham wrote:
> Ian G wrote:
> > I see! Tough one. Question of clarification - are you
> > saying that the status bar always displays the target
> > host name rarther than the domain field out of the cert?
> > That would mean that the status bar is simply another
> > confirmation of the original host.
>
> Yes, that is correct.
>
> This does mean that users don't have to do mental URL parsing to work
> out what the host is (avoiding [EMAIL PROTECTED],
> paypal.com.54535435443454345.mysite.com, and other such URL bar spoof
> attempts).
Right, I see how that could be useful.
> > Or it only displays the hostname from the URL when
> > there is no easy and positive match?
>
> That would be a useful enhancement.
>
> > Either way, this opens the way to click-thru-phishing.
> > After the click-thru has been tricked from the user ("win
> > a free cruise if you try out our new certificate and get to
> > the magic cookie") then the security UI goes on to
> > confirm the domain of phisher's choice.
>
> Could you explain in more detail how this would work?
Anything that can be done to convince the user
to click the warning dialog. So do a DNS poisoning
attack, and convince the user to go somewhere
when bankofamerica is the URL. When the domain
name doesn't match that found in the cert a popup
is put up there.
If the phish deliberately predicts and explains away
the popup, then when the click-thru happens, the
status bar then shows bankofamerica. Which is
now successfully MITM'd or spoofed.
Yes, it requires a click-thru.
> > Which means any interpolation - any advice that is
> > presented to the user - can be used against her /
> > her security. If the status bar shows a domain name
> > that came from somewhere else then that can be
> > spoofed (in theory).
>
> Can you imagine a scenario where (without the user having clicked
> through any dialogs) that indicator would be wrong? If so, file a bug,
> as the URL bar is similarly broken.
Essentially this would be an attack on the code
that matches the cert domain name to the host
name in the URL. But I agree, this original post
included an assumption of click-thru, I don't have
any indication that such an exploit exists.
> > Above you introduce a problem with this principle:
> > certificates may have various mappings and manglings.
> >
> > So the question arises - principle or convenience?
>
> It's not that simple. You have to demonstrate an attack which causes the
> UI to be wrong - and clicking through a "Whoa! There's something wrong
> with your SSL connection!" dialog does not count. If the user ignores
> such dialogs, they have no hope.
So what this suggests is a principle of the warning
dialog being dominating. That is, if the user clicks
through any warning dialog then there is no more
protection.
Defence in depth is not employed. OK, that would
be useful if there were a compelling reason here. I
would be uncomfortable with that as a principle, as
it would lead to a fairly clear line of attack.
Already, users are too de-sensitised to the click-thru,
so it doesn't actually function as it was intended. It
seems like there is no easy choice here, either you
design as if the popup dialog achieves something,
which we know to be unlikely, or one ignores it,
which means that we have to redesign quite a lot
of UI.
> > If one were to stick to the principle then one would
> > have to _interpret_ the mapping. For example, in the
> > above case, if you saw two subdomains then you
> > could display:
> >
> > <grey>mecha|<grey>rheet.mozilla.org
> >
> > when you matched the URL to rheet.mozilla.org,
> > and:
> >
> > <grey>rheet|<grey>mecha.mozilla.org
> >
> > if you matched the other domain.
>
> Ick. It would be far better if we resolved the pipe ourselves and just
> displayed the correct value - i.e. the one which the checking code used
> when it made sure that the cert really was for the domain we are on.
>
> That's not technically impossible - we just didn't have time to
> implement it before Firefox 1.0.
Sure. The only way to do this is to put quick
ideas in, made as a security fix, then see how
it test drives with users. Having put the status
bar domain name in, here's some feedback of a
time it didn't work out. Given a hundred such
experiences then we should generate a lot of
confidence. The more trials and tests and variants,
the more experience will be generated, and the
better things will be, IMHO.
> > with no shading. And the user might not quite
> > see what they hell that means, but this is the
> > security UI and that line is what you know, and
> > if the user can't work it out maybe that's because
> > there is a problem.
>
> If only users thought this way, they might be more secure. But there's
> no way something like this can be part of a simple consumer message.
>
> Currently the message is "check that the indicator matches the site you
> think you are on". It shouldn't need to be more complicated than that.
The message also needs to be precise. You
probably don't subscribe to this, but in about the
next 12 months or so, the messages are going to
have to satisfy a wider audience than just the
user. There will be a need for the UI to pass
muster under the most unfair of trials. The good
news is that MF's UI Is probably not the first on
the list.
> > For wildcards like *.mozilla.org, I'd be inclined
> > to do something like one of these alternates:
>
> * is easy - you just display the root. So *.mozilla.org would display
> "mozilla.org".
OK!
> Are there any other options other than * and |? Which standard covers
> such things?
On another front, did you see today's blog posting
about HCI/usability/KDE?
iang
--
http://iang.org/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
