lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.LNX.4.58.0503151844440.13371@linux.cc.stevens-tech.edu> Date: Tue, 15 Mar 2005 19:10:16 -0500 (EST) From: khockenb <khockenb@...vens.edu> To: Riccardo Murri <murri@...m.uniroma1.it> Cc: bugtraq@...urityfocus.com, Paul Smith <paullocal@...s.co.uk> Subject: Re: Thoughts and a possible solution on homograph attacks On Tue, 15 Mar 2005, Riccardo Murri wrote: > I would rather suggest that the string comparison function used in IDN > takes "homograph caracters"[1] into account: just like the current DNS > considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER > a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" == > "GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars. But that breaks case insensitivity for Greek, for instance (other languages, too, I am sure). Consider Greek letters eta and nu. A upper case eta looks like an upper case Latin "H", but a lower case eta looks like a lower case Latin "n". Similarly, an uppercase nu looks like a upper case Latin "N", but a lower case nu looks like a lower case Latin "v". If such a system as you suggest is in place, and someone in Greece wants the site (Greek nu).gr, they would have to have control of both N.gr and v.gr, otherwise people who type in the wrong case would go to the wrong site. Now let's say a competitor comes along, and wants (Greek eta).gr. They can get H.gr, but n.gr is already take, since N=n. I suppose we could get around that by making H=n=N=v(=V=H), but that would get cohfusivg.
Powered by blists - more mailing lists