Hacker News Reader

Comment by jandrese | Hacker News Reader

I assume this is Unicode in domain names?

I can't wait until I start getting phishing mails from domains that use unicode glyph collision attacks to make them look absolutely legitimate.

Oh, that's not a g in gmail.com, it's some East Asian character on the ass end of the Unicode character map that just happens to look exactly like a g.

View on HN

It doesn’t exactly work that way. Registrars only allow codepoints in specific ranges (the allowed ranges being different depending on the TLD)¹, so it ends up not being an issue (full FAQ here²).

Also, more information on internationalized domain names here³.

――――――

¹ — https://www.dynadot.com/community/help/question/IDN-not-regi...

² — https://www.dynadot.com/community/help/section.html?category...

³ — https://en.wikipedia.org/wiki/Internationalized_domain_name

These rules are designed to prevent you mixing codepoints from different languages, so you couldn't register something that looked like gmail but with the English 'a' replaced with a Cyrillic 'a'. However, if the name you're trying to emulate can be reproduced entirely within another language's character set, you can still impersonate an existing domain.

For example, it may surprise you to know that http://www.еа.com and http://www.ea.com are two different websites, despite the URLs appearing identical. Edge at least renders the IDN version in its punycode form, but in Firefox and Chrome the URLs are indistinguishable. It's quite possible that's a result of my messing with the IDN settings in the past, though - I'm curious what others see for those links.

I didn't know IDNs were a thing until today, and I see those two links as identical in Chrome.

This seems like a HUGE security fault.

Ah, that’s pretty interesting… wasn’t aware of that loophole!

Interestingly, Firefox 46 does show them both in non-Punycode form in the address bar (so they both look the same) while Safari 9 doesn’t¹; it shows the first URI as its Punycode representation.

――――――

¹ — http://i.imgur.com/rrNVlIj.png

This problem was largely "solved" years ago, when browsers, email clients, and major social networking platforms started showing the punycode representation of IDNs.

While that is the case for many programs, it’s absolutely not the case for modern web browsers. For example, navigating to はじめよう.みんな¹ in Safari 9² and Firefox 46³ does show the IDN as it’s supposed to look to the end user in the address bar.

(Of course, internally, it’s still represented as an ASCII string (using Punycode⁴)).

――――――

¹ — http://はじめよう.みんな/

² — http://i.imgur.com/KX5i9aW.png

³ — http://i.imgur.com/7WVeypl.png

⁴ — https://en.wikipedia.org/wiki/Punycode

I always set network.IDN_show_punycode to true in Firefox to force it to show me ASCII. Perhaps I'd feel differently if I spoke another language, but as it is, the risk of lookalike characters is too great to allow them to display.

I haven't particularly studied punycode, but since I first heard of it I keep thinking that it at least seems like it mitigates one set of collisions by allowing a different set of collisions. I mean, it seems unlikely someone would want the domain Mnchen-3ya.com, but wouldn't the city of München still be able to impersonate that person?

Would that be a collision though? xn--mnchen-3ya.com and mnchen-3ya.com look pretty different.

AFAIK if you use English application you see фртй as xn-hdyfh but if use Bulgarion application you see it as Bulgarian. Something like that.

Reply on news.ycombinator.com