3 ms·

The Unicode consortium maintains a list of “confusable” strings[0], that is supposed to be used to prevent domains being registered that are visually identical

The Unicode consortium maintains a list of “confusable” strings[0], that is supposed to be used to prevent domains being registered that are visually identical or near-identical to already-registered domains. As far as I can see, the characters used in this attack are indeed on the list. So presumably the problem is that not all domain registrars are checking this. I don't understand why ICANN or Verisign don't enforce this. This is hardly a new problem. Does anyone know the background to why this is possible? [0] http://www.unicode.org/Public/security/revision-03/confusablesSummary.txt http://www.unicode.org/Public/security/revision-03/confusabl...

mynegation 10y ago
It's not that hard to come up with legitimate domains in non-Latin script that could be recognized as word written in Latin script. For example, керас is a Russian transliteration of Keras. So I imagine they would get a bit of false positives and (fair) claims that non-ASCII languages are oppressed. To me, better alternative would be to limit puny code names to punycode TLDs, and make sure that no two TLDs look the same: task of much smaller scale.
- hyperpape 10y ago
  It's not necessarily a matter of oppressing non-ASCII languages if it's a symmetric relation. So if "epic.com" is registered using ASCII, that precludes registering the cyrillic version, but if it's already registered in cyrillic, that precludes it being registered in ASCII. There is a starting advantage for ASCII because so many domains were registered from English speaking countries in the early years of the web. But non-ASCII using countries are just as vulnerable to this attack.
- codedokode 10y ago
  Maybe non-latin domains should use non-latin TLDs? Or at least registrar should reserve all alternative spellings when registering a domain.
  - mynegation 10y ago
    Yes, that was my suggestion: non-Latin domains MUST be in the non-Latin TLDs, with additional constraint that non-Latin TLDs cannot look like already registered Latin TLDs. In a twist of irony, Russian word "сом" (roughly pronounced as "some") means "catfish" (the animal, not the action of catfishing though).
robin_reala 10y ago
That list is a great resource, but the one you linked to is 6 years out of date. The latest version is kept at http://www.unicode.org/Public/security/latest/confusables.txt http://www.unicode.org/Public/security/latest/confusables.tx... .
- robinhouston 10y ago
  Thanks! Although my linking to the old version was an accident, it's interesting that a) the old version explicitly says it's “for IDN”, and b) the characters used in this particular attack were already listed then. Here's a report of this attack from 2002, emphasising that it really isn't a new problem. Why on earth haven't the domain registrars acted? Or if they have, what went wrong in this case? [1] http://www.cs.technion.ac.il/~gabr/papers/homograph.html http://www.cs.technion.ac.il/~gabr/papers/homograph.html
deleted 10y ago
[deleted]
dheera 10y ago
Someone created apple.com ... https://www.xn--80ak6aa92e.com/ https://www.xn--80ak6aa92e.com/

mynegation 10y ago

It's not that hard to come up with legitimate domains in non-Latin script that could be recognized as word written in Latin script. For example, керас is a Russian transliteration of Keras. So I imagine they would get a bit of false positives and (fair) claims that non-ASCII languages are oppressed. To me, better alternative would be to limit puny code names to punycode TLDs, and make sure that no two TLDs look the same: task of much smaller scale.

hyperpape 10y ago
It's not necessarily a matter of oppressing non-ASCII languages if it's a symmetric relation. So if "epic.com" is registered using ASCII, that precludes registering the cyrillic version, but if it's already registered in cyrillic, that precludes it being registered in ASCII. There is a starting advantage for ASCII because so many domains were registered from English speaking countries in the early years of the web. But non-ASCII using countries are just as vulnerable to this attack.
codedokode 10y ago
Maybe non-latin domains should use non-latin TLDs? Or at least registrar should reserve all alternative spellings when registering a domain.
- mynegation 10y ago
  Yes, that was my suggestion: non-Latin domains MUST be in the non-Latin TLDs, with additional constraint that non-Latin TLDs cannot look like already registered Latin TLDs. In a twist of irony, Russian word "сом" (roughly pronounced as "some") means "catfish" (the animal, not the action of catfishing though).

robin_reala 10y ago

That list is a great resource, but the one you linked to is 6 years out of date. The latest version is kept at http://www.unicode.org/Public/security/latest/confusables.txt http://www.unicode.org/Public/security/latest/confusables.tx... .

robinhouston 10y ago
Thanks! Although my linking to the old version was an accident, it's interesting that a) the old version explicitly says it's “for IDN”, and b) the characters used in this particular attack were already listed then. Here's a report of this attack from 2002, emphasising that it really isn't a new problem. Why on earth haven't the domain registrars acted? Or if they have, what went wrong in this case? [1] http://www.cs.technion.ac.il/~gabr/papers/homograph.html http://www.cs.technion.ac.il/~gabr/papers/homograph.html

deleted 10y ago

[deleted]

dheera 10y ago

Someone created apple.com ... https://www.xn--80ak6aa92e.com/ https://www.xn--80ak6aa92e.com/