Closed Bug 843689 Opened 7 years ago Closed 4 years ago

Eliminate the IDN TLD whitelist

Categories

(Core :: Internationalization, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: dveditz, Assigned: smontagu)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want, Whiteboard: [adv-main43-])

Attachments

(1 file)

Once the algorithm in bug 722299 lands we no longer need the tld-based IDN whitelist because the algorithm is an embodiment of the reasonable rules already agreed to by the registries. The registries only control the domains they issue, however, so the algorithm is an improvement that protects against customers who create sub-domains that do not follow the same anti-spoofing rules.

After landing 722299 we can wait a release or two before removing the whitelist, to make sure nothing breaks.
No longer blocks: 722299, 840036
Depends on: 722299, 840036
Blocks: 840036
No longer depends on: 722299, 840036
As dveditz said in the security review, it might be wise of us to contact the listed registries and warn them that this is our plan.

smontagu: how hard would it be to write a tiny C++ app which took a list of domains on stdin and spat out a list of ones which failed the check on stdout?

We could then offer this app to registries who wanted to check on the impact it would have on their TLD, and give us feedback.

Gerv
Blocks: 1164788
dveditz, smontagu: should we just go ahead and do this? No-one seems to be challenging UTR#39 (and so our algorithm) as being the basic right way to do this. And, as noted in bug 1164788, the whitelist means that sub-subdomains of whitelisted TLDs get a free pass. This might be exploitable for places like appspot.com and its friends (or ones not run as competently) because people can see someone with addons.examplecloudprovider.whitelistedtld and register a subdomain to spoof the "addons" part with e.g. Cyrillic. 

Gerv
Flags: needinfo?(dveditz)
My chief concern is whether this would "break" (i.e. display in punycode) existing domains, which implies the question whether there are whitelisted domains whose registration policies are less restrictive than our display algorithm. Do we have any information on that?

Since the whitelist is pref-controlled, we can do this in the first instance by flipping the default value, and retreating will be easy if necessary.
> dveditz, smontagu: should we just go ahead and do this?

Of course I'm in favor, IMHO it's two years two late as it is.
Flags: needinfo?(dveditz)
Keywords: sec-want
smontagu: let's approach the compatibility issues by sending this change up to beta, and seeing if we get any bug reports. We can hold it back from release very easily - it's a single pref flip, right? (The use_whitelist pref.)

Gerv
Attached patch Flip the prefSplinter Review
https://treeherder.mozilla.org/#/jobs?repo=try&revision=aa438d4bcc34
Assignee: nobody → smontagu
Attachment #8612202 - Flags: review?(gerv)
*sigh* Bug 1172802 reminded me that we probably need a fix for bug 858417 before checking this in. Here's an example of a live IDN that gets punycoded if we turn off the whitelist: http://nam-việt.vn/
Depends on: 858417
Comment on attachment 8612202 [details] [diff] [review]
Flip the pref

Review of attachment 8612202 [details] [diff] [review]:
-----------------------------------------------------------------

r=gerv; but we need to monitor the compat impact of this, rather than just forgetting about it and letting it ride the trains.

Gerv
Attachment #8612202 - Flags: review?(gerv) → review+
Dan: are you OK with us checking this in and keeping an eye on it for compat?

Gerv
Flags: needinfo?(dveditz)
If Simon is "away" who will be keeping an eye on it? Sounds like there are at least two known and unfixed compat bugs in comment 7. But sure, checking it in is an improvement in my book.
Flags: needinfo?(dveditz)
(In reply to Simon Montagu away :smontagu from comment #7)
> *sigh* Bug 1172802 reminded me that we probably need a fix for bug 858417
> before checking this in. Here's an example of a live IDN that gets punycoded
> if we turn off the whitelist: http://nam-việt.vn/

Gerv pointed out that the Latin diacritics used in Vietnamese are all now "Allowed ; Recommended" in Unicode 8.0 so I will now check this in. (I am still "away" in the sense that I'm not working full-time on Mozilla code, but I am around enough to keep an eye open for regressions).
Keywords: checkin-needed
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/800c27046149
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Whiteboard: [adv-main43-]
You need to log in before you can comment on or make changes to this bug.