Security and Non-Latin Domain Name Characters

idn-ff-top.jpgI haven't made any hard predictions for 2010 yet, but it could be the first year of Internationalized Domain Name security threats.

A few months ago ICANN, the organization in charge of such things, approved the addition of top-level domain names with non-latin character sets to the public DNS. Several test domains have been created already.

And that's just the TLD portion of the domain name (like .com, .org, etc.). Non-latin characters in the other parts of domain names have been supported for some time. Together these are known as IDNs (Internationalized Domain Names) and their development is viewed by ICANN as an important part of helping the Internet to serve the whole world, not just the English-speaking part of it.

But for as long as they have been discussed, IDNs have also been known for the potential they create for security problems.

The most obvious form of abuse facilitated by IDNs is phishing. Completely foreign domains in non-latin characters may simply be confusing and fool some users just for that reason, but the real problem is that some characters in non-latin character sets are visually identical to latin characters. A Trend Micro blog shows this problem when the blogger registers two domains, a conventional and a Russian domain with Cyrillic characters that looks like "".

Non-latin characters are expressed as Unicode, an encoding format not directly compatible with DNS. The answer is "punycode," an alternative encoding in which Unicode characters are transformed into a standard ASCII character set in such a way that they are unique and reversible. In other words, every Unicode string corresponds to a unique punycode string which can be translated back into the proper Unicode syntax.

You can see some examples of IDN domains and try them in your browser on ICANN's IDNWiki. For example there is a Hebrew domain, including a Hebrew top-level domain (which I think is the Hebrew phonetic for "test". The domain name translates in punycode to xn--fdbk5d8ap9b8a8d.xn--deba0ad. Note that, this being Hebrew, the domain displays right to left. This domain can demonstrate for us another problem of IDNs at this point, inconsistent treatment by browsers (click on the images to see full-sized versions):

IE8: idn-ie.jpg

Firefox 3.55: idn-ff.jpg

Chrome idn-chrome.jpg

IE displays pure punycode, Firefox displays the actual Hebrew domain name, and Chrome shows the punycode domain name and the Hebrew page title. Note that the Hebrew domain in Firefox is displayed right-to-left to the right of a left-to-right "http://". It's not clear to me that this is better. We're mixing Vulcan and Klingon in the same line here, so it's not surprising that there's no clean answer. Browsers may react differently on systems which use different internationalizations.

One security analyst I asked said "if nothing else, expanding the TLD space expands the abuse footprint." It's not hard to see how this is true: The confusion between browsers alone provides some potential for sending users to some place other than where they want. The example demonstrated by Trend Micro is another.

At this point developers are working, to the extent that they are working on IDNs at all, with the goal of getting them to work properly. As they do that, and even once they think they have succeeded, vulnerabilities in the handling of punycode will inevitably come out. Remember, it's not just web browsers we're dealing with here, it's e-mail clients and servers, it's other web apps, it's anything that deals with domain names. That's a huge footprint of code that will have to be modified.

And when you consider how well current browsers handle IDNs, consider that the standard for them has been established for almost 7 years now, and existing software doesn't handle even well-formed IDNs properly. Imagine how long it will take for them to handle error conditions.

Software vulnerabilities and other malicious conduct aren't the only potential problems with IDNs. Adrian Kinderis, CEO of AusRegistry, enumerated some of the others in this article on CircleID. The way ICANN pushed the IDN process forward into a "fast track" brushed aside many concerns raised by constituents to whom ICANN normally listens intently, even excessively.

It's hard to see the IDN process going smoothly. It has to be many years before they work well with mainstream software and the major security bugs are worked out. In the meantime, watch this space for the problems that develop.

blog comments powered by Disqus