4 ms·

Introducing Internationalized Domain Name (IDN) Support

60 points by dwaxe 10y ago

jandrese 10y ago
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.
- envy2 10y ago
  This problem was largely "solved" years ago, when browsers, email clients, and major social networking platforms started showing the punycode representation of IDNs.
  - arm 10y ago
    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://はじめよう.みんな/ ² — http://i.imgur.com/KX5i9aW.png http://i.imgur.com/KX5i9aW.png ³ — http://i.imgur.com/7WVeypl.png http://i.imgur.com/7WVeypl.png ⁴ — https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode
    - sdkmvx 10y ago
      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.
    - deleted 10y ago
      [deleted]
    - bandrami 10y ago
      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?
      - arm 10y ago
        Would that be a collision though? xn--mnchen-3ya.com and mnchen-3ya.com look pretty different.
- arm 10y ago
  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-registered https://www.dynadot.com/community/help/question/IDN-not-regi... ² — https://www.dynadot.com/community/help/section.html?category_id=11 https://www.dynadot.com/community/help/section.html?category... ³ — https://en.wikipedia.org/wiki/Internationalized_domain_name https://en.wikipedia.org/wiki/Internationalized_domain_name
  - j4_james 10y ago
    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 http://www.еа.com and http://www.ea.com 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.
    - SomeStupidPoint 10y ago
      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.
    - arm 10y ago
      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 http://i.imgur.com/rrNVlIj.png
- darkhorn 10y ago
  AFAIK if you use English application you see фртй as xn-hdyfh but if use Bulgarion application you see it as Bulgarian. Something like that.
chrismorgan 10y ago
I don’t understand: why is this a feature that had to be added? IDNs are just xn--*, right?
- TazeTSchnitzel 10y ago
  Perhaps they wanted to check that IDNs were within valid character ranges (and therefore couldn't be a homoglyph attack).
- duskwuff 10y ago
  Their initial certification as a CA was contingent on disallowing IDNs, probably because they weren't yet fully prepared to recognize potential misuse of IDNs (like homoglyph attacks).
arm 10y ago
Yes! I’ve been waiting for this for quite a while now. Can finally get a certificate for my .みんな domain.

60 points by dwaxe 10y ago

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.

envy2 10y ago
This problem was largely "solved" years ago, when browsers, email clients, and major social networking platforms started showing the punycode representation of IDNs.
- arm 10y ago
  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://はじめよう.みんな/ ² — http://i.imgur.com/KX5i9aW.png http://i.imgur.com/KX5i9aW.png ³ — http://i.imgur.com/7WVeypl.png http://i.imgur.com/7WVeypl.png ⁴ — https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode
  - sdkmvx 10y ago
    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.
  - deleted 10y ago
    [deleted]
  - bandrami 10y ago
    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?
    - arm 10y ago
      Would that be a collision though? xn--mnchen-3ya.com and mnchen-3ya.com look pretty different.
arm 10y ago
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-registered https://www.dynadot.com/community/help/question/IDN-not-regi... ² — https://www.dynadot.com/community/help/section.html?category_id=11 https://www.dynadot.com/community/help/section.html?category... ³ — https://en.wikipedia.org/wiki/Internationalized_domain_name https://en.wikipedia.org/wiki/Internationalized_domain_name
- j4_james 10y ago
  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 http://www.еа.com and http://www.ea.com 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.
  - SomeStupidPoint 10y ago
    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.
  - arm 10y ago
    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 http://i.imgur.com/rrNVlIj.png
darkhorn 10y ago
AFAIK if you use English application you see фртй as xn-hdyfh but if use Bulgarion application you see it as Bulgarian. Something like that.

chrismorgan 10y ago

I don’t understand: why is this a feature that had to be added? IDNs are just xn--*, right?

TazeTSchnitzel 10y ago
Perhaps they wanted to check that IDNs were within valid character ranges (and therefore couldn't be a homoglyph attack).
duskwuff 10y ago
Their initial certification as a CA was contingent on disallowing IDNs, probably because they weren't yet fully prepared to recognize potential misuse of IDNs (like homoglyph attacks).

arm 10y ago

Yes! I’ve been waiting for this for quite a while now. Can finally get a certificate for my .みんな domain.