Re: houghts and a possible solution on homograph attacks
Sven Putteneers wrote:
> If this patch would be widely used, we'd lose the all the advantages
> associated with IDN.
I think that was the point.
IDN was not a very clever idea from the start -- it breaks the "don't
allow the obvious to not be what it appears to be" (aka "don't surprise
the user", etc, etc) rule which is one of the very most important rules
of any kind of technology/human interface. When you do break that rule
you get all kinds of "obvious" problems down the track, including very
many that should have been obvious at the outset, to the designer of
the system or functionality that did the breaking.
Such stupid and eternally regrettable design decisions have often been
strongly commercially motivated.
> Maybe it's better to attack this problem on the browser side and have a
Given IDN would seem to be here to stay, I'd say that will be the only
place we can attack it...
> configuration switch to enable or disable IDN. We could disable it as a
> "reasonable default", but those who need it, could enable it.
> Upon enabling the option, a warning dialog could pop up that warns the
> user about the security problems associated with IDN ("don't enable this
> unless you know what you're doing" stuff).
>
> That way the majority of the users would be safe from IDN attacks
> (phishing comes to mind) and those who really want IDN would have to
> click through a warning dialog telling them why enabling it may not be
> such a good idea.
Such warnings have far from sufficient efficacy. Much history shows
that the folk who will most likely "stupidly ignore" such warnings are
precisely the ones that would derive (most) benefit from the warnings
_had they heeded them_ (i.e. the folk who really need this protection
are the ones that will turn it off). The "let's pop up a warning
message" approach to truly hard problems such as this is a commonly
seen approach that shows the developer's total lack of understanding
_and_ caring about the actual problem.
Without having thought too hard about all this, a better browser-side
solution may be to not allow domain names with a mixture of ASCII and
IDN characters (I mean to the left of the unavoidably ASCII (??) top
level country, .com, .mil, .org, .net, etc domain name components). If
you have a Korean or Japanese or Mandarin or whatever domain name, then
there should be no need for any ASCII characters in it. There may be
problems with this idea with Central European names, where much of the
ASCII character set is employed along with a few special characters,
and with domain names that incorporate numerals. If IDN can be used to
encode characters from the ASCII character set too then these problems
are moot, but we end up back where we started in terms of mixed
ASCII/IDN-only chars being the "problem".
Of course, not allowing mixed ASCII/IDN does not entirely remove the
problem of "IDN-spoofing" -- for most suitably long domain names
(perhaps those with more than five _different_ caracters?) it is
probably a safe bet that there will not be a suitable set of IDN
homographs* possible to spoof your domain name, but for shorter ones...
* Being the semi-pedant that I am, "homograph" was always the wrong
term for these IDN spoofing tricks. A homograph is a pair of words (or
presumably more) that are spelt the same but have different meanings.
What we are talking about here are two (or more) words that are spelt
differently but look the same -- perhaps "pseudograph", if not the
right word, is certainly better.)
--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3267092