IDN Spoofing Strategy

After much discussion, staff@mozilla.org and drivers@mozilla.org have agreed a short-term strategy for dealing with the recently-publicised issues relating to IDN and domain spoofing.

First off, we want to make it clear: we support Opera’s position that this is a registrar/registry problem. These issues were known when IDN was proposed, guidelines were developed for avoiding the problem by restricting registrations, and the DNS registration organisations need to step up and implement them. (Certificate Authorities should also, as a simple matter of acting responsibly, not issue certs for domains which are part of a homographic block registered to two or more entities.)

However, we also have a duty to protect our users. So, in the mean time, the enableIDN preference will be set to “false” in Firefox 1.0.1 and Mozilla 1.8 beta, including all official localisations. An XPI will be made available to turn it on again; this XPI will make the risks of doing so clear. This means that by default, links to IDN domains which use the Unicode rather than the punycode form for the href will fail, and the browser will display any IDN domain visited in its raw form.

In the future (Firefox 1.1 and beyond) we hope to be able to turn IDN back on again. We may be able to find a way to turn it on selectively for those TLDs which have a demonstrable record of good practice – but we can’t promise to do that. It partly depends on how much resource maintaining a white or black list would take. (To help with that decision, please tell me of any instances where the registration of two homographic domains to different entities has happened in TLDs other than .com.)

So if people want to see full, unrestricted IDN back in Mozilla and Firefox, the best way is to put pressure on the world’s registrars and registries to fulfil their obligations to their customers – both domain owners and Internet users – and commit to implementing the ICANN guidelines.

53 thoughts on “IDN Spoofing Strategy

  1. idn spoofing plan

    We’ve been working for a while now to try to come up with a plan for routing around the IDN security problem created by a failure of some registrars to do the right thing when handing out domains. Today, it is possible to register a IDN homographs for …

  2. There are a couple of extension submissions for UMO that are supposed to help. The only one I’ve uploaded to UMO so far is the latest SpoofStick.

  3. Most users won’t need IDN, and this looks like a safe plan for those who don’t. But what about those who do need IDN? Even with a small whitelist of TLDs that appear to be following the rules, all it takes is for one phisher to get a homographic URL registered on one of the whitelisted TLDs and everyone who has IDN turned on is vulnerable again!

    I’d like to see a secondary line of defense, such as looking for “suspicious” domain names that have mixtures of characters from different languages. I’ve seen some suggestions for how to do this in bug 279099. This secondary defense may not be perfect, but a safety net with some holes is better than no safety net at all.

  4. Hi

    Why not have a gold bar warning every time you get homographs in different blocks being used, and also a dialog box with ‘DANGER’ etc writ large every time on a secure site?

    Banning IDN seems a step too far.

  5. And what about hacking an extension that would allow typing IDN in the address bar (and ressource query like img or such with IDN) – but won’t let clicking on a IDN link work (including linked clicked in external app)?
    Wouldn’t this be secure enough?

  6. IDN is great! Considering the recently implemented web protocols/standards, IDN was actually one of the larger achievements.

    I hope that a good solution will be found and that IDN will survive. This is another great opportunity to prove the quality of mozilla’s development process.

  7. Gerv,

    I worked for a few years as an evangelist to promote IDN support in Mozilla and I think of Mozilla as *the* forward-thinking browser developement project today. And yet I feel saddened today about this announcement. Turning off the IDN support would certainly hurt domain name registrars that have played by the ICANN rules and protected their clients and users and they would be hurt badly by this.

    Character-based spoofing goes on in the ASCII domain names but you’re not penalizaing these non-ASCII domain names. I feel that this is an over-reaction. While we try to settle on a good defensive measure, let me suggest a fairly simple and workable plan for now until a better measure is in place.

    The IANA has been accepting “Language Table” listings from responsible domain name registrars. The fact that they announced the language tables show that they thought about this type of phishing issues and restrict the registrations to a single language and to a limited set of characters. There are a few domains which have not published the table with IANA but have published them on their own home page.
    We can put them on the whitelist. There are only a dozen or so domains that qualify this. And almost all Asian domains where the largest number of registrations have taken place will benefit from this approach.

    If the drivers and the security team would like, I ‘ll be happy to provide an initial list of ccTLD and a few gTLD names that fit these qualifications. Turning off IDN will badly hurt Asian domain name registrars.
    Please re-consider and accept a whitelist as an initial step instead. This approach should be simple and you can even present a warning to .com IDN URLs saying that users ask the .com registrar to publish their language tables and limit the characters to avoid spoofing — if they want to see IDN support turned on in Mozilla for these domains.

    Cf.

    http://www.iana.org/assignments/idn/registered.htm
    http://www.iana.org/assignments/idn/

    Thanks,

    – Kat Momoi

  8. Please remeber people this solution is temporary, what i would like to see though is on the default homepage if you are using a IDN off build a link to the XPI and an explanation of the issue and why it has been temporaraly turned off.

  9. I agree–this is a problem that registrar’s are going to have to work out. Until a satisfactory solution is found, I agree that IDN should be disabled completely.

  10. Unicoder is right: this approach is far to anglo-centric. More importantly, his link is right. Please read it before you do anything drastic, like turning off IDN. It has some good ideas.

  11. I’d really like to be able to type a IDN domain. I don’t mind if it changes to punycode after that. But it’ll be a pain in the ass for things like .ch and .li domains where the only additional characters are � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �. You don’t have homographs there.

  12. Um yeh, why not allow homographs in hrefs and to be typed but convert to punycode for display purposes? I realise that its less than ideal but it’d be better than breaking IDN for everyone.

  13. Unicoder – An interesting post by Paul Hoffman, so thanks for link. However, I think you’ll find that Gerv is far from Anglocentric in his views on this subject. Take a look at his previous post for some interesting discussion on non-discriminatory methods to warn users of homophone spoofing:

    http://blog.gerv.net/007508.html

    Please don’t mistake a temporary protective measure for the final solution.

    Gerv – The Unicode report linked to by Hoffman looks interesting but doesn’t seem to propose much beyond the already suggested solutions.

  14. Unicoder is partially right, but I feel the solution proposed in the URL he mentions is just more of the same. Place an icon next to IDN domain names in the location bar? If you use IDNs often, you know you’re going to start ignoring it. Besides, what’s the deal with using tooltips over the IDN icon to convey information? First, it’s inaccessible to anyone who can’t see. Second, no one’s going to hover over an icon with the mouse — it takes far too long.

    That said, I like the basic concept he demonstrates. The highlighting method of illustrating the differences seems as tho it would have potential (if not in a tooltip). However, the places he says it would apply (IDNs with multiple scripts) is a joke. For example, consider this web address:

    Encoded version:
    https://www.раураІ.com/
    “Unicoded” version:
    https://www.\u0440\u0430\u0443\u0440\u0430\u0406.com/

    On this web page this address appears almost identical to the one it’s meant to spoof. (It doesn’t appear the same in the location bar or status bar, however, because I assume it gets normalized to lowercase before being shown – the “l” character is a capital Cyrillic I.) However, the “paypal” part is all in the Cyrillic subrange of Unicode. With his scheme it wouldn’t be an error.

    In the end I’m not sure what the best solution is here. Personally, I don’t really like this one. It’s good for ASCII users because they won’t notice a thing. However, it’s not going to provide a whole lot of safety for IDN users, because they will likely overwhelmingly install the XPI. Frankly, I think this solution stinks of the same school of thought as, “Users do read alerts!”

    Incidentally, whatever happened to the originally-proposed solution? That seems like it would have been a better idea to me, and I’m curious as to what disqualified it. I didn’t hear any particularly compelling arguments against it in the discussion after the fact in the bug.

  15. Kat Momoi’s suggestion are the way to go.

    It’s unresonable to punish ccTDLs for failures of the .com and .net registars.

  16. Great, because one American registrar doesn’t do its job, non-American users shall suffer. Why not disable https access to .com-domains instead? Alternatively make an US-localization without IDN support.

  17. Hy,
    I think your idea to turn of IDN as standart isn’t well. I’d loved this feature in FF realy.

    simon

  18. I’m quite borred to see that the solution is on the browser side, as a french web user I don’t want to see distinction between a french coded domain name and a us coded domain name.
    The solution to print different colors in the adress field is not good, what about B&W devices? and what about people affected of daltonism?

    I feel that the only solution is on the registrar side, they have to be more restrictive and create process to discover homograph problems…

    The internet is an internationnal area, I’m already disapointed to see that .mil and .gov already exists and not translated to .gov.us/.mil.us. I don’t want another distinction… Birth is the fruit of chance.

    All of us have to make pressure on registrars that do not respect the ICANN recomendations, I think it’s the only sane solution in the way of freedom and equity.

  19. Mozilla disables native IDN support

    In an idiotic move, Mozilla has decided to disable native support for IDN domains.

    I personally have been able to get dozens of people to convert to Firefox because it supports IDN domains, by disabling IDN without notice you are not only making my li

  20. To the folks complaining about turning it off (and maybe Gerv could make this clearer in the post for those that aren’t familiar with the release schedules)…

    A solution to the problem is needed immediately (Firefox 1.0.1 should be out in a few weeks, and has to be released to fix other security problems), so unless an effective solution can be agreed and coded in the next couple of days, the options are to turn off IDN, or to leave things as they are now.

    I think the statement makes pretty clear that Mozilla doesn’t want to be anglocentric, and does want to come up with a proper fix for the next releases.

  21. Re: “Besides, what’s the deal with using tooltips over the IDN icon to convey information?”
    I (choose to) understand it to mean that letters/background would always be colored, but the ledgend that tells what the colors mean is show when hovering (or clicking the icon).

    “First, it’s inaccessible to anyone who can’t see.”
    If they can’t se, they shouldn’t have a problem (at least my screen reader doesn’t read non-ascii letters as ascii letters)

    “Second, no one’s going to hover over an icon with the mouse — it takes far too long.”
    Then click it.

  22. I think this is a perfectly reasonable short term solution…IDN can still be used, but the majority of the people who don’t need it won’t have to worry about it. Having a tooltip is not exactly a great solution, its just going to confuse a lot of people who don’t know what IDN, phishing, or anything technical are, or those people will just ignore it

  23. As someone who is paying a good registrar (.at) for an IDN domain, it’s hard to understand why IDN support should be taken offline for testing builds (or more?) instead of at least wallpapering over the problem in a way that it works for most consumers (e.g. blacklist the few known bad registrars, only allow a certain range of characters for now, or something similar).

    I’d understand if this came up shortly before the actual release and it would be disabled on the release branch only. It would be hard to accept that my domain would stop to work for users where it had been working already, but well.
    Disabling fo non-stable testing releases (previews, betas) is something I can hardly understand though.

  24. As far as user experience is concerned, the best solution is a warning box similar to the one FF gives for “http://www.paypal.com@evilsite.net” type spoof attempts. This is a good compromise between correctly implementing a useful-but-abusable standard and protecting the user. It would be even better if the dialog box gave a third option: to whitelist the site for URL login names.

    Similarly, the warning box for an IDN link should explain the problem in simple language, ask for confirmation, and allow for whitelisting of the domain. Whitelisting the TDL could be an option found somewhere in the preferences, but probably doesn�t belong in the warning dialog. A related preference could specify which characters in the domain name would trigger the warning — The most paranoid setting could include even ASCII �1� and �0�, which could fool the exceptionally gullible. A more generous setting would only trigger the box if the character combination �looked� suspicious, with the suspicion code subject to easy updates of course.

    This isn�t the simplest solution to code, but it will provide a user experience that is cutting-edge in both safety and features.

  25. Mozilla Foundation schaltet Support f�r Umlaut-Domains ab

    Wir berichteten berichtet vor kurzem �ber einen Phishing-Trick mit den internationalen Domainnamen, welcher sich als schon seit vor deren Einf�hrung bekannt herausstellte. Trotzdem scheint viele erst die neuliche Demonstration mit dem gef�lschten paypal.

  26. I think this has already been suggested, but it seems to me like the obvious solution is to keep a list of Unicode characters that resemble ASCII characters. When an IDN is entered, Firefox should use that list to convert the IDN into ASCII and see if that domain exists. If so, it should prompt the user and ask whether it should go to the ASCII version or the IDL.

    Sound good?

  27. Who needs IDN? There are 26 letters and 10 digits you can use to build an URL. You can make virtually infinite combinations with that many characters.

    IDN = I Don’t Need!

  28. And another thing: Most of the French/Spanish/Italian etc. letters look just like the English 26 except for a tiny bit of punctuation. So is the punctuation so vital to anyone but a grammatical purist?

    In a website URL you could substitute a plain N for the N with a tilde, or a plain C for the cedilla, etc.

    The ONLY practical use for IDN is to CAUSE DELIBERATE confusion, as in the example of substituting an accented A for one of the A’s in “paypal”.

  29. Simple solution:

    Disable IDN for all .com domains.
    Enable IDN for all ccTLD.

    1. It’s easy.
    2. Fixes the real reason of the current trouble.
    3. Has the least side effects. (non-English users…)
    4. Doesn’t require GUI changes.

    If IDN is compleatly turned off many will reenable IDN and your action will be only PR without real security effects.

  30. Much simpler working IDN solution, just use the regular browsers with/or without any IDN preparation to enter special characters in the URL (http://….) line and let the DNS take are of the rest, without any runtime programs on either end – just the DNS data is to be prepared correctly – as proposed 2001 and published in the USPTO application No. 20040139086.

  31. And another thing: Most of the
    French/Spanish/Italian etc. letters look just like the English 26 except for a tiny bit of punctuation. So is the punctuation so vital to anyone but a grammatical purist?

    Yeah – and let’s not allow 1 because it’s too like l, and 0 because it’s too like O. In fact, we should disallow j because it’s too like i when links are underlined.

    Gary: I’ve responded to Paul Hofmann’s blogpost in my “clarification” follow-up.

    Delian: We may well end up with a solution something like that.

  32. Plans for Scams

    Gervase Markham has written “a plan for scams,” a series of steps for different module owners to start defending. First up, the browser, and the list will be fairly agreeable to FCers: Make everything SSL, create a history of access…

  33. Das aus f�r IDN?

    Die Unterst�tzung f�r IDN (Umlautdomains) wird wohl aus Mozilla entfernt. Ich halte das f�r einen verdammt schlechten Scherz Schlie�lich wurden die Domains als die Zukunft gepriesen. Und Deutsche trifft es ja "nur" mit den Umlauten. Die Chinesen

  34. I sincerely hope that Neil is joking, and in fact realizes that not all languages use the Latin alphabet.

  35. In all my tests, on almost 100 machines, disabling the IDN entry in Firefox then restarting the browser has not effect. During the current session it stops any URLs using the punycode, but upon restarting this change has no effect.

    AdBlock is the only way we can fix this issue in my organization.

    I hope someone sees this entry.

    john

  36. John: there’s a bug in Firefox 1.0, which is fixed in the latest nightlies and will be fixed in 1.0.1, where that pref doesn’t work properly.

  37. If the IDN is a kind of Spoofing possible (combined with more than one script language), show a raw punycode at the address bar. Otherwise, IDN show normal if IDN has only one language scrip. This is a simple and easy for a short term solution…long term could be more developed..

  38. Turn OFF IDN? Are you insane? I would expect that from Microsoft and it’s totally American/Anglocentric point of view, but not from Mozilla who (theoretically at least) draws from many different cultures! Besides, MS IDN is busted anyway.

    I strongly recommend that Mozilla reconsider and use this solution (or one like it) instead: http://lookit.proper.com/archives/000302.html

    I wish I had the time and the knowledge to implement it myself and donate the code.

    (reading comments above as I type this, I see the above URL has already been posted, and I note that most of the international community has already come down HARD on Mozilla – AS THEY SHOULD HAVE. To disable IDNs is a short-sighted and silly decision.)

    PLEASE PLEASE PLEASE reconsider!

    As for those who think IDN is useless, all I can say is that the arguments against it seem to me like very typical ill-informed, uneducated, Anglo-centric twaddle that doesn’t deserve any more comment than this.

    cheers,
    Marc

  39. Countries that use languages other than American? Maybe we should mobilise our forces to save them from the tyranny of their own language?

    Any resistance and we put them in Camp XRay…

  40. As a native english speaker, with minor interest in far eastern languages, and major interest in a global internet, I have to say that this strikes me as nothing less than small-minded discrimination.

    It could be argued that what you have done is equivalent to Microsoft extending HTML in proprietary ways as a “temporary solution” to HTML’s inadequacies. Some people think it’s fine, but others feel the impact greatly, both on a practical level of less relative functionality and on a social level of becoming a second-class citizen. What’s worse, of course, it the bad precedent it sets.

    If you cannot do something non-discriminatory, then please do nothing, and wait for a better solution. Security is important, but as someone said, those who give up freedom for security deserve neither.

  41. For David:

    Nation of birth may be a thing of chance, but the Internet was not created by chance. It was created in the United States. So the United States having sole use of the .mil and .gov domains is entirely within its rights.

  42. I may merely be showing my ignorance here but there seems to be something that could usefully be done.

    Top level domain names are much abused – everyone and his dog has a .com URL and it now means nothing. It should be a rule that if a particular country top level name is used then the rest of the URL must use that country’s character set. This could be enforced both at the browser level and at the DNS server level.

  43. “Nation of birth may be a thing of chance, but the Internet was not created by chance. It was created in the United States. So the United States having sole use of the .mil and .gov domains is entirely within its rights”

    Yeah yeah… but the WWW was invented by a British man- just like your nation! :)

  44. @Alan Barnard: It should be a rule that if a particular country top level name is used then the rest of the URL must use that country’s character set. This could be enforced both at the browser level and at the DNS server level.

    Excellent idea – correct me if I’m wrong, but I don’t think anybody would have a positive use for a domain with one country’s suffix and another one’s character set. They will be able to use suffixes of different countries with the same character sets (eg Germany and Austria), however, I this this will vastly cut down on the amount of abuse. After all, who needs a domain name in the Chinese character set with a Russia suffix, for example?