Mozilla Drops Support for International Domains

tsu doh nimh writes "Netcraft has the story that Mozilla has decided to drop support for international domain names in future versions of its Firefox Web browser. The decision comes after demonstrations by the Schmoo Group that the feature can be used to aid in phishing scams and other browser naughtiness." From the article: "The attack can be disabled in Firefox and Mozilla by setting 'network.enableIDN' to false in the browser's configuration (enter about:config in the address bar to access the configuration functions). The Mozilla development team today made this the default setting. Users who want IDN support will be able to turn it on, but will be warned about the risks involved."

Comments

Drops?

[Anonymous Coward]

They've disabled it by default until they come up with a long term solution. That's hardly dropping.

Re:Drops?

[Anonymous Coward]

They've disabled it by default until they come up with a long term solution.

I think you mean "disabled it until the registrars get their acts together".

Re:Drops?

[GrenDel Fuego]

Actually I think it's funny how people are so quick to defend Mozilla and say it's not dropping anything. The grandparent is right to point out that they are indeed dropping support. It doesn't matter if they're temporarily turning it off. They're turning off support. They are dropping default support in future versions of Firefox.

I think what we have here is a terminology conflict here.

Support for computer software can mean "ability to use" (eg. does linux support SCSI hard drives?) or "ability to get help with" (eg. is linux 2.2 still a supported kernel?)

IDN is still supported in that the functionality still exists on mozilla once it is turned on.

It is not supported in that it's known broken, and you use it at your own risk if you enable it.

Re:Drops?

[Rodness]

Now I understand why the Mozilla community consistently blasts Slashdot for "not getting it". Lately it doesn't even seem like the submitters are even bothering to read the articles before they rush to post their mental mucus.

Mozilla has temporarily disabled internationalized domain name handling until they figure out a long term fix. This is not 'dropping' anything. They're not ripping out the IDN code, they're just trying to protect their users while they figure out a fix, and most of the English-speaking world isn't even going to notice a difference anyway.

That's False

[Uruviel]

It will be turned of in the 1.0.1 But for 1.1 and further releases they will look for a more cleaner way to fix the spoofing issue. And thus brining back IDN support. Here is a link to the Mozillazine article: http://www.mozillazine.org/talkback.html?article=6 073

Re:That's False

[Qzukk]

A fix is pretty easy, but requires two parts:
1) Amend the IDN spec to require that valid IDN urls use the lowest-numbered codepoints that match that glyph.
2) Have browsers use a table that identifies all the characters that share a glyph. Any invalid IDNs are mapped down to the lowest codepoints before the browser goes there, so a link to a fake paypal.com address actually goes to the real paypal.com address.

Of course, this still can't stop people who just refuse to look closely at the URL. The payqal.com domain is taken, who knows what its used for...

Re:That's False

[JanneM]

1) Amend the IDN spec to require that valid IDN urls use the lowest-numbered codepoints that match that glyph.

"Match the glyph" is a _very_ vague concept - and the degree of visual likeness will depend on the currently chosen fonts. Japanese half-width romaji looks very different from western monospace. Or extremely similar. It all depends on the typefaces you use, your locale and so on.

2) Have browsers use a table that identifies all the characters that share a glyph. Any invalid IDNs are mapped down to the lowest codepoints before the browser goes there, so a link to a fake paypal.com address actually goes to the real paypal.com address.

But they really don't share a glyph. Mostly, this has already been done when Unicode was defined; in fact, at some codepoints they were overenthusiastic and reused some glyphs they really shouldn't have.

Just because two different glyphs will look very similar with some combination of typefaces (but, note, not with other), it doesn't mean they aren't very different and should be treated like it.

Example: in sans-serifed fonts, I (caiptal "i") and 1 ("one") will tend to look very, very similar. With your suggestion, all "I":s will thus be changed to "1" in registered url:s everywhere.

The problem is rather the opposite, actually. WHen you don't have the real typeface needed, the browser (or font system, really) tries to substitute the missing glyph with something similar, which is a good thing when you try to read text. It can make an URL look different from intended, however. One step of the solution may well be not to accept this kind of substition in URL:s. No idea if you can get this kind of control, though.

Fix it now.

[Anonymous Coward]

From Chris Smith via BoingBoing

1) Goto your Firefox address bar. Enter about:config and press enter. Firefox will load the (large!) config page.

2) Scroll down to the line beginning network.enableIDN -- this is International Domain Name support, and it is causing the problem here. We want to turn this off -- for now. Ideally we want to support international domain names, but not with this problem.

3) Double-click the network.enableIDN label, and Firefox will show a dialog set to 'true'. Change it to 'false' (no quotes!), click Ok. You are done.

4) Go check out the shmoo demo again and notice it no longer works.

Re:Fix it now.

[el_gordo101]

5) Close all instances of Firefox, restart Firefox
6) Go check out the shmoo demo again and notice it works again.

This "fix" only works temporarily. Once you restart the browser, it reverts back to the original behavior.

Re:Fix it now.

[Anonymous Coward]

1. Type "about:config" in the URL bar, then scroll down to network:enableIDN -> double-click and set to false;

2. Go to "Tools" -> "Privacy" and clear the cache;

3. Then restart Firefox. You are now protected.

Clearing the cache is a mandatory step.

Temporary fix does not work..

[slashkitty]

This was discussed before, but the temporary fix, of setting it to off, doesn't work in current versions. Apperently the setting wasn't reloaded when the browser was restarted. I hope they fix that as well. In the mean time, please do NOT recommend the temporary fix to people, because it makes them think they are safe when they are not!

Re:RTF...what?

[Lisandro]

Seriously, it says it RIGHT THERE. I quote:

"This is obviously an unsatisfactory solution in the long term and it is hoped that a better fix can be developed in time for Firefox 1.1,"

I found hard to beleive a serious project like Firefox would drop IDNs so easily. It's a huge world, you know.

Correction

[Stiletto]

The submitter SHOULD have mentioned that Mozilla has decided to disable internationalIZED domain names, ones made of "funny" unicode characters.

International domain names like .uk .au, and our favorite, .cx, are of course still supported.

Re:network.enableIDN

[mikeophile]

Clear your cache in Tools/Options/Privacy and restart Mozilla. Or go here and try this. /thank BoingBoing

Re:How about selective INT Domain Filtering?

[PurpleFloyd]

This isn't about turning off domains like .kr. Rather, it's about turning off Unicode support in domain names - currently, in browsers which support IDN, it's possible to send someone to a URL which looks like "https://www.paypal.com" but really has a letter replaced with a non-English Unicode character which looks the same. This deactivation turns off support for Unicode domain names, not national domains.

hmph

[miruku]

have they not read this?

Re:hmph

[Myen]

Yes they have. Or at least somebody working for MoFo has.

Re:Internations

[cthrall]

Ahhhh...the point of the scam is a domain name that looks like www.paypal.com in your browser but redirects you to something eeeeevil.

See the pretty demo.

Re:network.enableIDN

[scovetta]

Or use my fix: http://www.scovettalabs.com/advisory/SCL-2005.002. txt in corporate environments (or home use too).

IDNC3

[StarDrifter]

D. J. Bernstein (djbdns, qmail, ...) saw this problem coming back in 2002. He proposed an alternative to IDNA called IDNC3 which he claimed wouldn't cause this kind of mess. Looks like nobody listened to him though.

Re:IDNC3

[evilviper]

DJB is hardly a prophet. He predicted that new (greek) characters that looked like ASCII characters could be used to make an alternate URL that looks like it is legitimate. Big whoop. Anyone with a double-digit IQ and any grasp of the internet could have predicted the problem long before 2002. Back when I was signing on to Compuserve on a 286 running DOS, I could have told you that the rendering different characters similarly would pose problems with site verification.

The solution, however, is not to eliminate the number 1, or the letter L from our keyboards, but to use decent FONTS in our web browsers. I generally use Bitstream Vera Sans, which does a fair job of differentiating between similar characters. An ever better solution would be for fonts to appear in different COLORS. If all numbers in URLs appeared BLUE, while all letters appeared GREEN, and all foreign characters appeared RED, you couldn't possibly confuse them. Most governments have figured this out decades ago, and design their currency in this way.

Even fixing this will only stop the current wave of tricks. The underlying problem is that the internet (and computers in general) is just pieced together from spare parts. Things like SSL are just added on-top, and you're lucky Netscape programmers were even smart enough to put a Lock icon in the browser.

These issues are everywhere, and just waiting to be exploited. I heard from someone, not long ago, that installed SSH and connected to a server, and noticed that his data was being transfered in clear-text. Now, the problem was just that the client and server couldn't agree on a mutual protocol, other than null, but the real problem is the lack of communication from the lower-levels of the program, to the user. OpenSSH has simply removed the NULL cipher for reasons such as this, but that's just another quick fix that doesn't really solve the problem, and will come back to haunt us in a few years.

All this stuff NEEDS to be re-designed to be robust, and I don't mean handling strange errors behind the scenes, without telling the user. We lack the fundamental system design needed to put together a solid system from the ground-up, rather than piecing hacks on top of programs to temporarily eliminate the most common flaws that are exploiting fundamentally poor designs.

Can you identify an IDN?

[jfengel]

The problem is that you can't always easily identify an international domain name. In particular, IDNs contain characters that are nearly identical to Latin character set but are treated differently. Slashdot won't let me put in examples, but examples here.

The paypal.com one is particularly scary. It looks like paypal.com in your status bar when you hover over the link. It reads paypal.com in your address bar. But it isn't Paypal. That's because the "a" isn't an "a" but is really Unicode D0B0 If they'd put any effort into making it look like Paypal, it would be easy for somebody to direct you there and steal your Paypal password.

In Firefox and IE they're indistinguishable. Even if they added a clue that something was different (e.g. colors to indicate an IDN) you'd have to look closely, and if IDNs became common you'd start to ignore the color coding. If the only difference between "paypal.com" and an identical spoof were small, you'd get tired of looking closely, and forget. If the warning was unignorable, like a popup, you'd turn it off.

So the upshot is, yeah, beware of web sites you don't know, but with IDNs you don't always know whom you know.

Re:Internations

[Tackhead]

> If you ever go to an international domain name you such be looking out for scams anyway.

No, no, no. IDN's aren't about country codes, they're about special character codings that result in things in your status bar that look like their ASCII equivalent characters, but aren't.

Don't worry, that special site hosted in Christmas Island will continue to resolve just fine. :)

Not International domain names.

[northcat]

Not International domain names. Internationalized domain names.

Real solution...

[Sylver Dragon]

A real solution for this problem is posted here

The applicable part is:
1. Install the Adblock Firefox extension.
here
2. Look at the Adblock 'Preferences' and go to 'Adblock Options'

3. Tick 'Site Blocking'

4. Add the following filter :-
/[^\x20-\xFF]/

Re:NOOOOOO!!

[northcat]

No, it's not dropping support for country specific TLDs (did i use the right term?). .cx, .us, .de etc., will all work. It disabled support for Internationalized domain names. Internationalized domain names are domain names with characters from non-english languages. http://www.verisign.com/products-services/naming-a nd-directory-services/naming-services/internationa lized-domain-names/index.html. IE doesn't support this too. It's all in TFA.

a fix for Firefox under Linux

[SilveRo_kun]

From your home directory, enter the .mozilla/firefox/*.default folder; then with vim open compreg.dat, and search for the string: "idn-service;1" (use the / function). Change the 1 to 0 in both the strings you find. Now, restart Firefox.

The url will still appear spoofed at the bottom-left corner of the browser, but if you click on the proof-of-concept link it won't work.

Re:How about selective INT Domain Filtering?

[Anonymous Coward]

To my knowledge, there is only one way to encode the latin letters in UTF-8. They don't have any redundant code positions in Unicode, do they?

They don't, but they do have multiple code points that are commonly rendered to the same glyph (yet have different collation behavior, etc.) In these example exploits, the Cyrillic "o" (о = о = U+043E [*]) is used in place of the Latin "o". It looks identical, but it's a different domain.

[*] - It's in this Unicode code chart.

Re:network.enableIDN

[athakur999]

Clearing the cache doesn't make setting network.enableIDN to false start working. The compreg.dat method you linked to also is not a permanent fix as that file is recreated everytime you install an extension.

The AdBlock method does work though.

Re:network.enableIDN

[athakur999]

That's talking about making changes to file 'by hand' using an external editor. If you use about:config, the browser itself keeps track of the change and modifies prefs.js according when you close it.

Why don't you give it a try?

As if!

[Anonymous Coward]

Anti-slash is in no way responsible for this glorious event. In addition to your web site being down for weeks, your organization has been totally ineffective and irrelevant, and I'd be surprised if there were more than one or two of you who actually were active in Anti-slash.

I realize that you *tried* to expose editor injustices, but your months-old, hastily written, totally incomplete little list of Michael's offenses, along with whatever goatse'ing or other juvenile shit you might have done, was of no use. Instead, it was my repeated assault of detailed, informative anti-michael first-posts that likely made the difference.

Re:network.enableIDN

[ptlis]

On the contrary, it does. At least for me: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0 I closed down all windows, cleared the cache & history, typed about:config into the Address bar, disabled network.enableIDN and then restarted Firefox.

Re:Mozilla is an American project

[LadyLucky]

American? Hmm. Lead Developer was in my class in Auckland, New Zealand.

Re:It's like curing calluses by chopping the legs

[ockegheim]

I've been a long-time web user, can speak French and German, have done a lot of trawling German sites for information, yet had no idea that anything other than ASCII was available for URLs. I think it's a good solution for most English speakers, especially monolingual English speakers until something better can be worked out.

Re:Better

[dreamer-of-rules]

..l..0..1..O..I

They did consider the implications, compared them to the security risks users were already exposed to, and suggested that the applications (this being an application-layer protocol) visually distinguish IDN or mixed IDN domains.

http://www.faqs.org/rfcs/rfc3490.html

Check out sections 1.2 and 10.