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: <6.1.0.6.2.20050311100408.057d6ec0@lmail.pscs.co.uk> Date: Fri, 11 Mar 2005 10:42:47 +0000 From: Paul Smith <paullocal@...s.co.uk> To: nick@...us-l.demon.co.uk, bugtraq@...urityfocus.com Subject: Re: Thoughts and a possible solution on homograph attacks At 00:48 09/03/2005, Nick FitzGerald wrote: > > 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... Personally, I think the best place to attack it is at the registry - unfortunately most of those are bound by commercial motivation instead of trying to be good citizens, or help Internet users in general, so it might be harder to change their behaviour than change browser behaviour. My proposal would be: 1) IDNs only allowed on ccTLDs (not gTLDs). After all , the whole point of IDNs is to have a domain name in the locally readable script to target people within your own region/nation/etc. gTLDs are to have domains to target people globally. I see no purpose (other than vanity) to having an IDN in a gTLD . 2) IDNs should only be allowed to consist of a single character set - be that Latin, Western European, Japanese, Cyrillic etc. 3) A ccTLD should only allow IDNs in their local character set(s). So, you couldn't have a cyrillic IDN on a .us domain, and you couldn't have a greek IDN on a .ru domain. (4) A domain registry's DRS system should take into account homograph/pseudograph attacks. (5) Possibly any domains containing only characters which are graphically equivalent to latin characters should not be allowed, but I'm not sure of this one. I think if IDNs followed these rules they would still keep most of their benefit, but also make it MUCH harder to have a homograph/pseudograph attack. (1) is needed as it's still possible to make up certain words using characters from the cyrillic and/or greek (and possibly others) character sets that look like words from the latin character set. Having this rule limits the scope of these possible attacks to people in Russian or Greece (2) is needed for (hopefully) obvious reasons (3) is needed for the same reason as (1) (4) Obvious This leaves (AFAICS) the only possible attacks being in Russia or Greece (and possibly others with similar character sets) to a very few domains. For instance EBAY.RU would still be possible using 0415, 0412, 0410, 0423 as well as 0045, 0042, 0041, 0059. But, there is only this single combination of cyrillic characters which could resemble the 'proper' EBAY.RU. If you don't have rule (2), then you could have lots of different combinations, eg, 0045, 0412, 0041, 0059 etc. So, having rule (2) means that eBay could register (or use DRS to regain) a single extra domain to protect themselves and their customers, instead of 16. Rule (5) would stop even this, but it could cause problems with legitimate Russian or Greek words which contain only Latin characters. This really needs behavioural investigation. For instance, if a Greek Internet user saw WWW.KAPPA.GR (or www.<another greek word which can have greek or latin letters), would they type in 'KAPPA' in Greek letters, or in Latin letters? I suspect they'd type it in latin, in which case rule (5) would be OK, but if they'd type it in greek, then rule (5) would not be OK. I think limiting the protection to browsers has several problems: - it stops IDNs from having most of their usefulness - it makes browser development more complicated due to no fault of theirs - in countries where IDNs are widely used, they're still open to attack as they'd *have to* enable IDNs to be able to use the Internet adequately - it doesn't just affect browsers, it affects email clients, chat programs, ftp programs, news readers, etc etc etc Even if my 'rules' were optional, well behaved registries could use them, and advertise they use them, then browsers could warn (or un-IDN-ise) IDNs from other registries, but show IDNs from the well behaved registries in their proper character set. Paul VPOP3 - Internet Email Server/Gateway support@...s.co.uk http://www.pscs.co.uk/
Powered by blists - more mailing lists