Elliotte Rusty Harold wrote: > Interesting tidbit: app1e.com (not APPLE.COM but APP1E.COM) is in > fact already registered. This attack may not be as theoretical as I > initially thought.
And a0l.com. (It even has a website: www.a0l.com.) [Which, incidentally, induces a security hazard, by attempting to download "a free/10 sec download that fills forms and brings offers based on websites you visit", offered by The Gator Corporation -- even authenticated by Verisign. But would *you* trust a free download offered by "The Gator Corporation", even if it is really them?? Those guys are bigtime ad-spy facilitation gators, all right.] But this kind of stuff is old news, as other examples raised by people have shown. > The problem needs to be fixed closer to the source. It simply isn't practical to try to "fix" the problem of visual spoofing by trying to prevent it in the character encoding, or for that matter in the text-based protocols. As Barry Caplan pointed out, there are other, more robust means of determining trusted identity, to foil the cases like your Bob and Alice email scenario. But of course, the best technology won't prevent stupid, gullible people from falling into traps set for them by unscrupulous, cunning scam artists. And nobody is going to keep the dedicated industrial or military spies from finding ways to crack supposedly secure systems, if for no other reason than secure systems are administered by fallible humans. > The Unicode community > has been in serious denial about this for some time. That other > technologies also have or contribute to these problems in no way > absolves Unicode of its problems. Well, yeah, I guess I'm still in denial. *hehe* As Asmus, and any number of other people on this list have pointed out, the same problem of Latin/Greek/Cyrillic letter spoofing that has you so worried is present in any number of other 8-bit character sets, and because of the nature of the writing systems, the nature of case, and the requirements on textual processing, would still be present in any alternative to Unicode that some other character encoding committee could come up with. Even if we sat down to do it all over again, with a big "Security Is Our Primary Concern!" banner posted on the wall for every committee meeting, Unicode 2 would still end up with separate Latin, Greek, and Cyrillic alphabets encoded. Not to do so would make any proposed new standard crash and burn before it left the runway. The only widely-deployed alternative approach I know of is ETSI GSM 03.38 (used in mobile telephony), which has Greek (uppercase only) added to Latin, using the same codes for the uppercase Greek letters which look like Latin (ABEHIKMNOPTXYZ). But this approach is so patently nonextensible and so unworkable for any significant text processing requirements, that SC2, ANSI, or other major players in character encoding have never seriously considered such an approach for character encoding. So perhaps turnabout is fair play here. I'd say that a certain portion of the security community has been in serious denial about the nature of character encodings for some time. --Ken
