Opera Fixes IDN Spoofing in Opera 8.0 Beta 2

Opera Watch writes "Opera has introduced a fix for the IDN spoofing security vulnerability in its latest beta version. The new version, Opera 8.0 beta 2, was released today on its FTP directory. No official announcement from Opera yet. Opera has created a white list for safe top-level domain names which include .no, .jp, .de, .se, .kr, .tw, .cn, .at, .dk, .ch, and .li. Sites not in the white list will show the encoded domain (with the IDN characters) in the URL field. The list is updated automatically when Opera checks for a new version."

Comments

Why a whitelist?

[Anonymous Coward]

Did opera decide nobody in .cn would ever build a paypal lookalike with a domain that looked like "paypal"?

Re:Why a whitelist?

[Ahnteis]

I think they're guessing the ".cn" on the end would be enough to tip off the wary user.

Re:Why a whitelist?

[crow]

The list is based on the URL that you're visiting, not the country you're browsing from.

But your point is valid. Many businesses set up contry-specific websites (e.g., amazon.co.uk), so those sites will be vulnerable to this spoofing for Opera users using local sites in those countries.

Re:Why a whitelist?

[dolphinling]

No. Unlike Verisign, the .cn registrars are responsible and don't allow domain look-alikes.

Re:Why a whitelist?

[Noksagt]

Except that uk & other country-specific sites that are most likely using Latin1 rather than UTF-8 will probably not be whitelisted.

I agree that a whitelist is only a work-around, but if you only whitelist the countries who would be more likely to use UTF-8 for real sites with their own characterset (rather than to spoof other sites), it isn't too bad to use right now.

Re:Why a whitelist?

[Anonymous Coward]

To quote the article,

TLDs are considered safe if they have implemented anti-homographic character policies or otherwise limited the available set of characters to prevent spoofing.

In other words, the whitelisted TLDs do not allow domains to use the characters that look like standard letters.

discussion @ opera.com

[Arctic Dragon]

It's been 'unofficially' announced in the Opera Forums

Need a standardised solution.

[Aspirator]

We need an internationally agreed solution to this. ICANN are understandably upset at the slight that has occured to a large part of the world. Mozilla's browser couldn't reliably turn IDN off, that was fixed, but now it's off by default. The more officially proposed solutions are mostly registrar based, I don't think that's OK. Opera now has a fix of it's own. IE hadn't even got round to implementing IDN. The problem has been known about for ages, but only recently taken seriously. It certainly is serious. It only matters for secure sites, where one expects that the site is run by who it appears to ben run by. Typing in all secure URLs is unrealistic, they are often quite long and cryptic after the domain name. How about a query button for secure sites which will reliably show the domain owner data, e.g. if one clicks on the padlock?

Re:Need a standardised solution.

[Anonymous Coward]

Take a look at the above mentioned Beta 2. Opera displays the certified name of the certificate owner inside the address bar along with the padlock icon. Clicking it will show more extensive information, although that is not usually needed.

Why is this so hard to fix?

[curunir]

It seems like you could pretty easily compile a mapping of foreign characters to the ASCII characters they could impersonate. Then, when a foreign url is entered, it could first be looked up with the ASCII replacements to see if a site exists. If it does, that site would be returned instead. If not, the internationalized URL would then be loaded. Results could be cached by the browser so that this check would only be needed the first time the site was loaded.

This way http://www.mïçrõft.com would bring up MS's site and the attempt to impersonate would fail. It would also have the added benefit of sending host headers to the real site which, combined with referer headers in the site's logs, could help them track down the scammers.

Whitelists ignrore third-level domains.

[molo]

The problem with whitelisting TLDs is that this ignores problems with bogus third-level domains/hosts. The listed registrars prevent registering look-alike domains, but no one controls look alike third-level domains.

For example, ωωω.paypal.jp (using greek omega). This can be combined with a DNS cache attack.

-molo

Re:Whitelists ignrore third-level domains.

[Anonymous Coward]

I don't understand your point. To do that, you need to be in control of paypal.jp already, in which case why bother with spoofing?

If you're talking about making misleading third level domains under your own domain name, there's also no need to spoof anything. It's already possible to set up paypal.mydomain.com without having to resort to obscure character sets.

Re:Whitelists ignrore third-level domains.

[molo]

No, you can do a DNS cache poisoning attack. It is pretty hard to DNS cache poison a address like www.paypal.com because it is already in the cache of most DNS servers (because of the site's popularity). But, there is nothing stopping you from cache poisoning a hostname that no one has tried to connect to yet.

Say for example I'm a phisher and am trying this attack. I send my phishing spam to all of the earthlink.net accounts I have, using the IDN url. At the same time, I start a DNS cache poisoning attack, using spoofed DNS packets that look like they come from paypal, sending to all the known earthlink DNS servers. The DNS servers accept the spoofed packets when they do a query, poisoning the cache. All the client sees is the whitelisted Unicode URL.

-molo

Because...

[brunes69]

Because some people in the world know more languages than English (yes, I know it is hard to believe!) and they want their domain that they legitimately purchased to work properly, even if some characters in it it happen to look simmilar to some other English letter.

Re:Because...

[Anonymous Coward]

Do you speak English? Because most people that do invariably spell "similar" with one M.

Re:Because...

[curunir]

No, I believe it...I speak 4 myself. But I still don't see any issue with checking ASCII domains first. Your internationalized domain would still work fine so long as you didn't register a domain that looks similar enough to confuse with an existing all-ASCII domain. If you did, that's tough.

Trademarks exist for a reason...to prevent confusion for consumers. You are from Canada, so answer me this: would the Canadian government grant two trademarks that were otherwise identical except for one had a 'ç' in place of a 'c'? I doubt they would.

Domains are analogous to trademarks and the primary goal should be to eliminate confusion on the part of the user. If you have a legitimate complaint (i.e. you owned your domain first or something of that nature) against the holder of the all-ASCII domain, the UDRP should be able to handle this.

Perhaps this should be enabled on a per tld basis where appropriate(i.e. .com, .net, .org, .edu, .mil, .gov, .us, .uk, etc), but I still stand by my assertion.

Re:Because...

[hkmwbz]

"I still don't see any issue with checking ASCII domains first."

And your first language is English?