Firefox IDN .com .bug

[white_crane]

Firefox IDN .com bug

Firefox doesn't work with IDNs in .COM .NET or .EU

A bug has been filed.

Help get FireFox working with .COM .NET and .EU idns by voicing your concern.

https://bugzilla.mozilla.org/show_bug.cgi?id=542562

 

[Szise]

I think it's an anti phishing measure not a bug.

 

[white_crane]

I think it's an anti phishing measure not a bug.

Antiphishing should not block legitimate IDN use, especially in localized FireFox versions. This is a bug.

 

[Szise]

Please read here:

Firefox fix plugs security holes - CNET News

 

[white_crane]

Please read here:

Did you notice the date on that article? 2005.

 

[ajkula]

Firefox is supporting IDN but will only show the URL for domain that are white listed.
The .com domain is one of the domains that are not white listed for safety reasons (spoofing).

Network.enableIDN - MozillaZine Knowledge Base
Network.IDN show punycode - MozillaZine Knowledge Base
Network.IDN.whitelist.* - MozillaZine Knowledge Base

source Thu 07 of Jan, 2010 21:55 PST

 

[Number37]

This policy is nothing but political protectionism of the English dot com space.

It's making an assumption that IDN won't be legitmately used in dot com. Latin character set extended characters are commonly used in romance languages.

It's a two way street. French languages domain names for instance can just as easily be spoofed using non diacritic versions of the letters as vice versa. And different diacritics can be used to spoof other diacritics.

Firefox should flag extended characters with a visual indicator but allow the use of IDN. Blocking by default is discouraging open language support. If you're going to do that, why bother having the support in the first place?

 

[white_crane]

It's making an assumption that IDN won't be legitmately used in dot com. Latin character set extended characters are commonly used in romance languages.

Very true. It is an ethnocentric view to begin with.

 

[Domagon]

VeriSign who runs the .COM registry, which your IDN is regged in, is the problem.

.ORG and numerous other TLDs, including many ccTLDs, are white-listed because their respective registries make an effort to disallow potentially abusive registrations.

On a related note, since abuse can easily happen in other language sets, this it not an ASCII (Latin-1 to be more precise) only situation.

VeriSign needs to more aggressively filter IDN registrations for similar looking domains and enforce character set usage (ie. not allow mixed sets nor improper language tags).

Ron

 

[Number37]

In investigating this issue, I've found a few things that weren't known to me or clear before:
Some of this was mentioned earlier above

These are what I found in my case. Your mileage may vary.

- Firefox is not blocking the IDNs
- Firefox is replacing the IDN with the punycode in dot coms by default in the address bar display
- Adding a boolean config entry to firefox network.IDN.whitelist.com=true will display the IDN value.
- Firefix does the DNS lookup in punycode regardless of the setting

- Some DNS servers are blocking (or not accepting?) Latin-1 diacritics.
- Verisign is not blocking and is only really involved in whois lookups directly. The DNS servers are handling the lookups once the nameserver assignments have propagated.
- My ISP accepts diacritics in dot coms for DNS zones. But the requests are reaching them already converted to punycode.
- whois from the Windows command line replaces diacritics with dots before making the request and does not convert to punycode so IDN fails regardless of the upstream configuration or may actually retrieve the wrong record.
- ping from the Windows command line refuses to access DNS and tries a WINS/Broadcast lookup instead.
- whois from linux uses punycode

I think a warning or color flagging of extended letters is a better solution than replacing the domain with punycode. Just posting a support article at the mozilla site is woefully insufficient for users. Developers often lose sight of the fact that end users are usually not technical. Failing to realize this has been a big stumbling block for linux acceptance at the desktop level.

It's likely in the future that the IDN version of a domain name will have a stronger claim than the Anglicized version when the domain is based on a French word. e.g. passé.com vs passe.com The Firefox defaulting policy favors the Anglicized version.

It's unclear whether registrars are creating records that are in IDN form or just translating punycode form back on demand. In the future will the IDN forms be automatically activated for direct access without punycode?

My solution was to register the domain in IDN form at the registar, who converted it to punycode in the registration whois record, though they maintain the IDN display in the management interface. The domain is configured in the DNS zone at my ISP's nameservers using the punycode name. This resolves the lookup problems, but doesn't correct the Windows cmdline flaw (W2K and Vista). I've actually configured both forms at the nameserver for now.

 

[thefabfive]

All IDNs are represented in punycode at the DNS level. That is the reason for the punycode - to represent Unicode characters as an ASCII-only code so that it is compatible with the current DNS system. When doing lookups for whois, some services have a built-in punycode converter so you can use unicode, others do not. For DNS you should always use punycode.

Something that may not be clear to everyone: IDN in Unicode = IDN in punycode and vice versa. Or for better visualization: москва.com is equivalent to xn--80adxhks.com and vice versa.

The current DNS does not support Unicode so xn--80adxhks.com should be used when configuring nameservers. But configuring xn--80adxhks.com will mean the same as configuring москва.com.

The firefox "bug" is not a bug but a choice made by Firefox out of fear and ignorance in an attempt to control phishing attacks. Nothing more.

 

[white_crane]

The choices made by the developers result in a "bug" for end users, and that is what really matters, not the technical mumbojumbo.

Verisign, which runs .com, accepts characters defined as valid in the punycode spec, nameprep, which certainly limits the number of characters from the entire unicode range. Some are valid, others are invalid.

I don't see why Mozilla can't just look at the punycode conversion spec and use the list of characters provided there.

 

[Number37]

All IDNs are represented in punycode at the DNS level. That is the reason for the punycode - to represent Unicode characters as an ASCII-only code so that it is compatible with the current DNS system.

Punycode is not just for unicode. It also encodes extended ASCII as I detailed earlier.
IDNs are represented in punycode at the DNS servers for lookups, but not universally at the DNS configuration level. Moniker for instances displays registered domain names in the proper langauge and provides the punycode in the tooltip. Registration is handled using the language specific letters. And my ISP's nameserver allows entry of domain in any language. So at the raw lookup level it's punycode but above that, anything goes.

Most of the user confusion stems from the mixed formats. Are users taught in any fashion that xn-- indicates a non-english character set, that it might be a fraud site? No.

The average user when confronted by www.xn--micrsoft-73a.com is going to interpret that as related to microsoft. People already see citibank.com when shown citbank.com or citibank.com.cn and that makes phishers successful. How displaying punycode is supposed to solve this for anyone but techs is beyond me.

An on-screen warning indication is what is needed. That's the solution provided for SSL, and it's one users are already familiar with. The punycode process should be hidden from the end user. At the very least, a first occurrence popup explaining what xn-- in a domain name is would be more useful.

If anything, they xn-- display will have the opposite effect - accustoming the user to the xn-- format and teaching them to accept nonsensical displays without question. The user never sees the special character in micrôsoft.com if the phishers show him www.xn--micrsoft-73a.com instead. But when he arrives at a microsoft look-alike site, he's more likely to ignore any fears and just assume it's another microsoft distribution site.