Slashdot Mirror


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."

7 of 365 comments (clear)

  1. network.enableIDN by athakur999 · · Score: 5, Interesting
    The attack can be disabled in Firefox and Mozilla by setting 'network.enableIDN' to false in the browser's configuration


    Isn't this the "fix" that everyone found stopped working after you restarted the browser?

    --
    "People that quote themselves in their signatures bother me" - athakur999
  2. Simple answer... by andreMA · · Score: 3, Interesting

    Wouldn't rendering the characters in question as black-on-red in the status and location bar be a more effective solution? Or the entire background changes to red to warn the user that the characters they can read aren't the "actual" characters in the domain name?

  3. OUtstanding! Smart defaults by redelm · · Score: 4, Interesting
    I have always maintained that one of the keys to powerful software is carefully chosen defaults. Otherwise, there simply is too much for the user to learn before they see the value in learning it.

    Perhaps some of the international versions of Mozilla will have Int'l name _enabled_ by default. A quick peek at $CHARSET would do.

  4. Re:Honest question by Anonymous Coward · · Score: 4, Interesting

    Yes, There are plenty, especially in Sweden and northern Europe. Take for example vävtak.se.

    Anyway. I think this solution is truly bad. IDN is a fundamental change we need to the internet. Not only to incorporate local languages on to the Internet, but also to increase the number of available choices.

    Disabling IDN is really bad. Instead, as suggested by someone else here, the registrars should prevent/ban addresses that will look the same on screen as existing ones.

    In fact, couldn't Mozilla instead do a simple test and see if the domain name exists without the hidden characters. If it does then it should warn the user about it.

  5. Make IDNs more obvious by Mr.+Sketch · · Score: 3, Interesting

    Why don't they just make it obvious you're visiting an IDN? Similar to how they handle SSL sites, the location bar background turns yellow. Maybe for IDNs, they can make it red and flashing or something similar, so it's obvious to the user that something may be wrong. Maybe they could check and see if there is an equivalent looking domain name in english and then making it red and flashing to let the user know that it may not be the site they think they're visiting.

    There just seems to be other ways to handle it, since it really is more of a 'user beware' issue.

  6. Re:That's False by Alsee · · Score: 2, Interesting

    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.

    Setting aside other issues, I'd say that is very very VERY bad implementation. If the browser is given an invalid address then the browser should not invisibly guess at rewriting it into a valid address. Better to have invalid addresses trigger immediate errors and be killed off / corrected in the first place. It would be an absolute nightmare to encourage impossible to trace down bugs caused by quasi-valid and conflicting addresses that took identical and inexplicably sometimes go to the right place and sometimes don't. Remember, that address may pass through a chain of 14 different programs from different sources potentially in varying orders. Imagine clicking on a pseudo-valid address in an e-mail going through the e-mail program and through spam filter and through a proxy and off to a browser and throgh another proxy then to the local IP stack and then out to the DNS system and back to the local IP stack and through your ISP's proxy and cache and THEN first going out to the website.

    At some effectively random point it gets changed into a completely a different address. A different address which looks identical to any human attempting to hunt down a bug. It's worse than looking for an invisible needle in a haystack, you haven't even figured out yet that you're looking for a needle much less an invisible needle.

    -

    --
    - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
  7. Re:Known broken? by LittleBigLui · · Score: 2, Interesting
    Well, RFC 3454 mentions this kind of attack briefly:


    The Unicode and ISO/IEC 10646 repertoires have many characters that
    look similar. In many cases, users of security protocols might do
    visual matching, such as when comparing the names of trusted third
    parties. Because it is impossible to map similar-looking characters
    without a great deal of context such as knowing the fonts used,
    stringprep does nothing to map similar-looking characters together
    nor to prohibit some characters because they look like others. User
    applications can help disambiguate some similar-looking characters by
    showing the user when a string changes between scripts.


    So no, that doesn't resolve it, but it recommends a (general) way to deal with it.

    Obviously, Mozilla should have followed that recommendation instead of ignoring it.
    --
    Free as in mason.