Hacker News Reader

Comment by userbinator | Hacker News Reader

For reference, the example is using:

    U+0435 CYRILLIC SMALL LETTER IE
    U+0440 CYRILLIC SMALL LETTER ER
    U+0456 CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
    U+0441 CYRILLIC SMALL LETTER ES

...which are basically indistinguishable from the corresponding ASCII (65 70 69 63) in most if not all fonts.

I don't see this as being an easy or even solvable problem in general --- after all, a Russian IDN registrar could rightly argue that it should be valid to use all Cyrillic characters in IDNs; but at least for those of us who are content with English-only domain names, we can just disable IDN.

I suppose one solution would be, when IDN is detected, to show both the Unicode and Punycoded versions:

[www.xn--e1awd7f.com]https://www.epic.com/

One could also argue that this is also a usability feature, for easy copying of IDNs by those who otherwise cannot write them.

View on HN

Didn't Firefox show puny code in the url bar once?

The problem is quite old. [1] is a 12 year old bug report on this very problem in Mozilla.

https://bugzilla.mozilla.org/show_bug.cgi?id=279099

Yeah, I remember this vulnerability getting a lot of attention back when that bug was filed. I don't remember how the browsers decided to fix it, but there was some kind of fix. What happened in the last decade that changed that? And what went wrong in the browser-makers' processes for the underlying issue to be forgotten or overlooked?

>I suppose one solution would be, when IDN is detected, to show both the Unicode and Punycoded versions:

That looks like the best solution. The security certificate of the site shows the punycode version of the URL. If the address bar URL and the certificate URL are different, then, at least for addresses in English, that should raise an alarm.

If the address bar URL and the certificate URL are different, then, at least for addresses in English, that should raise an alarm.

There's a mention below ( https://news.ycombinator.com/item?id=14119826 ) that some browsers will show the IDN in the certificate too, presumably because it would otherwise be equally confusing if they didn't match (they do match.) This isn't a problem that can be solved without showing both the IDN and punycode.

no-one checks the certificate readout - it'd have to be inline for regular users to see any benefit.

The least-impact visualisation could be using colors: group the characters in the domain name by script family, then use regular colors for the largest group (so that e.g. an all-Korean domain name would look just fine) and highlight those exotic relative to the rest.

or maybe just disallow mixed-charset domains. After all there's not much use for a domain that's partially Cyrillic and partially Latin. Not that I'm aware of anyway - and the rule could be more granular if there are legit uses.

this makes a lot of sense

see https://news.ycombinator.com/item?id=14120372 - this example uses all-Cyrillic

the point is that is reduces the number of potential variations. There would only be 1 or 2 possible visually-identical phishing domains for any latin domain, as opposed to potentially hundreds or thousands as it stands now.

Isn't it possible to detect the mixture of cyrillic vs english and so on?

This particular example was chosen such that the entire name was using the Cyrillic Unicode range:

https://en.wikipedia.org/wiki/Cyrillic_(Unicode_block)

From that, you can see domains composed exclusively of those characters with are homoglyphic or nearly so with the ASCII equivalents would be susceptible to this:

AaBCcEeFHhIiJjKMOoPpSsTXxY

That's not all the letters, but there are plenty of domains in English which can be written to look the same with entirely Cyrillic.

When I generate all the English words that are in a UK dictionary that use the letters "acehijopsx" exclusively, and then test which are reachable domains, I come up with only about 500. Other than epic.com, the most significant ones are chase.com, sap.com, soap.com and sex.com, I think.

I've said this for years now. This is an old exploit that could be 100% preventable with ASCII-only URLs. I remember, the last time I said this here I got downvoted to oblivion for stating the true and obvious.

Yes, why should people from outside of a narrow few countries be able to use the web in their native language?

Everyone should learn to speak English like normal people, is that what you're trying to say?

As a non-native English speaker: Yes (English is my 3rd language).

There is a set of simple, clearly defined symbols (ASCII) that make up the URL. It must be like that for URLs to be ever secure. If the URL can be made of tens of thousands of symbols, some of which are completely identical, the URL will never be secure.

It also really changes how naming goes though for a lot of sites and limits the non-English speaking world to have to compete for website names in English when perfectly equivalent words exist in the native language. If a Russian upstart wants to have a simple site like зоомагазин.com or .рф they shouldn't have to compete for the name petstore.com, competing for a name that they don't use, isn't in their country even, and can't possibly be competition. Plenty of shops and and businesses here use .рф addresses alongside those that transliterate Russian to English. Limiting to just ascii characters removes options and artificially inflates the value of common and simple domain names, forcing a bidding war where there doesn't have to be one. Simple sanity checks for mixed character urls by the browser easily remedies this.

One only has to look at things like passports, where internationally-significant naming is important, to see that English (and thus transliterated names) is the norm:

https://en.wikipedia.org/wiki/Passport#Languages

Simple sanity checks for mixed character urls by the browser easily remedies this.

Except this particular example, the name 'epic' is written entirely with Cyrillic characters. One could argue whether a Russian company has the right to use such a name (with all-Cyrillic characters), or how it would be input --- and if you want it to be easy to input for those who don't completely have IDN support and matching ways to input those characters, you'd have to also display the punycoded version, at which point a transliterated name would be better anyway.

I'm not sure that there really are that many full word collisions across two different alphabets. Epic versus Ерис is certainly a nice example, but how many others are there? (Also, I know there is a character that can be used to look like the latin Ii, but every time I see the и character or sound, it's always Ии, but that's not really what this is about) And honestly, I do think that Ерис.com has every right to be a site as Eric.com - it would be trivial for a browser to know whether the url was provided in latin characters or cyrillic.

My point/question is more "is the issue actually words in two different character sets creating a collision or mixed alphabet collisions?" If it's the former, I'd like to see more examples to show this is a prevalent issue that wouldn't be caught by a sanity check that catches URLs with mixed character sets. (That is, how many unique words across languages are there that actually get a hit this way, in the same way Epic/Ерис do?)

As for passports, I understand your point on the universal nature of English, but International passports serve a completely different purpose than a domain name. So much of the web is non-english, save the domain name for some of them, and I'm not sure why it has to be this way. If the owners want it that way, great. If they want a domain in the local language, I'm not sure why they shouldn't be allowed to. A passport is meant for a very specific set of people (border guards, law enforcement, airline and other travel employees) to be able to verify your identity. A domain name just needs to resonate with its audience.

I just don't see why every business across the planet needs to compete for the same flowers.com address, or petstore.com, or cars.com. There are plenty of unique words and ways to communicate the same idea, I'm not certain why we need to restrict ourselves to English here. It just makes already expensive domain names even more expensive. If I have a club in San Francisco that I wanna call White Nights, there's no reason that a club in St. Petersburg should have to compete with me for the same name when they have their own term for White Nights, especially when the issue seems to not be about foreign character sets, but mixing character sets in the domain name. All ascii does work, but it's a grenade for an anthill.

Edit: an aside, I didn't realize that Safari translates to punycode. Very cool.

>зоомагазин.com or .рф they shouldn't have to compete for the name petstore.com

There's already a .ru domain. And why would it want petstore.com instead of zoomagazin.com? Everyone is able to transliterate to Latin here. Many years have passed since .рф was introduced and almost nobody is using domains in Cyrillic. Sites that use Latin domains are much more popular. At this point it's safe to say that non-ASCII domains is a feature that nobody really needed (except for phishers, of course).

Reply on news.ycombinator.com