RSSOpera Calls for Consortium on IDN Fix
By Nate Mook | Published February 18, 2005, 3:50 PM
Opera Software has called on its fellow browser makers and the Internet community as a whole to band together in an effort to fix the security issues related to Internationalized Domain Names. The IDN standard was called into question earlier this month following news that it could lead to domain spoofing and phishing attacks.
The problem with IDN stems from its use of the Unicode character set to enable domain names that include international letters. But because the DNS system that facilitates the Internet only understands ASCII, or U.S. English characters, Unicode URLs must be converted by a Web browser into a format called "Punycode."
In this conversion lies the potential for a malicious Web site to mimic a trusted URL, including its SSL security certificate. With Unicode, it is possible to have numerous characters called "homographs" that appear identical when displayed, but are actually completely different.
For example, paypal.com using a Unicode Cyrillic a actually loads up the URL: xn--pypal-4ve.com. But the Web browser displays the Unicode character as it would a standard ASCII letter, leaving the user unaware of his actual location on the Web.
"Technically speaking, Opera and other non-IE browsers run into a problem because they have implemented a standard correctly," Carsten Fischer, Opera's VP of Desktop Products, told BetaNews. IE is immune to the issue because it has yet to natively support IDN; however, a VeriSign plug-in can provide the functionality.
Earlier this week, Mozilla developers announced the next release of Firefox would disable IDN as a temporary corrective measure until a long-term solution is found. Opera says it will provide its own fix in an upcoming preview release of Opera 8, while noting any "solution must find a balance in how information is presented to the user."
One of IDN's authors, Paul Hoffman, was quick to respond to the press reports and dismissed suggestions to simply drop support for the standard. "Given the assumption that billions of people would actually like to have their domain names be in characters that they use every day, there has to be better solutions to the homograph spoofing problem," Hoffman wrote on his Web log.
Hoffman suggested creating a pop-up that informs a user when they visit an IDN domain that contains multiple character sets. "The difficult question is how to show the pop-up in a way that alerts about spoofing but doesn't get in the way of normal IDNs," he said.
But Opera's Fischer said URL display is a complex issue. "Pop-up warnings are clearly not a workable solution, and visual clues need to be sufficiently to the point - though not obtrusive for valid URLs, while remaining conspicous enough for unusual cases. This is a difficult balancing act."
Fischer did not suggest a solution, but said the problem will require some kind of user interaction and educated decision-making. "This is why we believe this problem cannot be solved alone, but rather together with members of the Internet community. This has to become a joint effort of browser vendors, domain name registries and certificate authorities."
"Together we can find solutions that can ban suspicious character mixing and give certificates additional trustworthy information that is difficult to spoof," Fischer said. "This is a problem for the entire Internet society."
In Paul Hoffman's blog, linked to in this story, he suggested that that browsers could perhaps put an icon to the left of the URL indicating it is an IDN address. The problem is that the people most vulnerable to phishing schemes won't have a clue what this even means. You and I likely know how to avoid falling for phishing attacks, but what about the so-called "newbies"? Even if the browser showed an in-your-face indication that the current site has an IDN domain name, will these users even know what that means? Or will they just go straight for the close button like they do with MSIE's activeX security warning?
It's only a slight consolation that most of these "newbies" are still using MSIE, which is currently invulnerable to this potential phishing scheme.
Score: 0
|The new beta versions of Opera have a function to have read out loud to you. Try it on these two words below. Highlight and press V. (assuming you are using 8.0 and have voice installed).
paypal.com
pаypal.com
Even though the two LOOK the same they SOUND different.
I created a button that will read the current url.
http://my.opera.com/foru...readid=81752#post837949
edit: Betanews messed up my test case by not showing the IDN addres.
Score: 0
|When the flaw was reported they quite harshly stated that they had IDN implemented correctly and that it wasn't their problem.
Score: 0
|There's a new version of SpoofStick for Firefox to address this issue:
http://www.corestreet.com/spoofstick
Score: 0
|This is what I did for MultiZilla:
MultiZilla (for Mozilla) makes use of secret hash key for SSL protected sites and displays a warning for new/unknown sites, with or without IDN, with data taken from the SSL Certificate to inform you (the user) what site and organization you are visiting. Note that I use two different warnings/prompts for this.
The saved hash key will be checked next time you visit the site, to ensure that you are visiting the right site, and MultiZilla will inform you (read display a warning) when it didn't find a hash key, or when it found one for a different script. Note that protection works in both ways i.e. normal domain -> idn and idn -> normal domain.
We also display the organization, also taken from the SSL certificate, instead of the visited host (normally taken from the URL) in front of the security lock (see also: http://multizilla.mozdev.../spoofing/fake-host.jpg)
and MultiZilla also changes the background color of the location bar to orange (see also: http://multizilla.mozdev...oofing/unicode-host.jpg) for URL's with IDN, but note that the URL will be displayed as punycode, after you enabled it on MultiZilla's pref panel.
Here are a few other screenshots:
http://multizilla.mozdev...oofing/new-ssl-site.jpg
http://multizilla.mozdev...oofing/new-idn-site.jpg
Note: the Unicode will be replaced with punycode (in Mozilla builds 20050218 and up), if you set the pref, see also my next screenshot)
http://multizilla.mozdev...-support-pref-panel.jpg
Score: 0
|Hopefully something comes of this. Even the Fx team is having a hard time figuring out a fix so they, starting with today's nightly, are simply disabling the feature by default.
Score: 0
|NOW they're calling for a fix?
What happened to "it's the standard and to spec so we're doing nothing"?
Hypocrites.
Score: 0
|Opera had correctly stated that the main problem is with the IDN system. You can quote them from a quote of a quote if you want to call people names, but Opera software has acknowledged since this became public that something needs to be done. They had pointed out that as this is an agreed standard, they cannot just pull IDN support, and it still is the case that registrars are far better positioned than browser vendors to crack down on this.
As we all know, getting a system which is clear enough for potential phishing attempts while NOT bothering the user on valid domains is very difficult to do. Opera has discussed with its userbase many options, but it is clear more discussion is needed to come up with the most robust solution...
Score: 0
|Hey, I call them as I see them. The folks in ZillaLand did the responsible thing and said they'd try and do a fix. When they couldn't, they indicated that they would dropp support.
Slice it any way you like - the Opera folks did not indicate that they had their customer's best interests at heart with their first reaction. The folks building a free product did. It kind of paints them in a less than optimal light.
Score: 0
|Fx is not dropping support. They are simply turning it off. The user can, in a few clicks, easily turn it back on. That's not a true fix. To be fair, if MS did the same thing (in any situation), people would be all over their backs. Something needs to be done and not only at the browser level. The standards themselves will need some serious review.
Score: 0
|I agree completely.
The process of ratifying them also needs a serious overhaul with security in mind so that this mess doesn't happen again.
Someone was asleep at the wheel.
Score: 0
|A recent article in one of the Tech journals I follow is worth consideration.
Have domain registrars limit the use of non-ascii (unicode) characters to ".country" domains. Those who desire to use "international letters" in their domain names could do so by registering the domain under their country code (eg: ".se", ".no", ".ru").
¤§ TBear §¤
Score: 0
|I'd agree that 'native' language support should only be available in country name domains.
In any event, if I see "foreign" characters in a URL, I'll close that site at once. I don't really know where its going and I will not be able to read the site once there even if it is legit.
Score: 0
|the problem with that is you WONT see foreign characters in spoofing URLs. Commen sense though, will tell you to type in paypal.com rather than clicking a link that supposedly goes to paypal.com
Score: 0
|