Closed Bug 1444551 Opened 7 years ago Closed 7 years ago

IDN mixed charset domain names

Categories

(Firefox :: Address Bar, enhancement, P3)

58 Branch
enhancement

Tracking

()

VERIFIED DUPLICATE of bug 1332714

People

(Reporter: akostadinov, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #1332714 +++ Firefox/58 This is a clone of Bug #1332714 because I couldn't comment on it for some reason. First I'm a Bulgarian speaker and use Cyrillic on a daily basis. I find it highly dangerous to allow mixing Cyrillic and Latin letters in domain names. * It allows phishing and multiple indistinguishable domain names. * Then it would be very annoying to type such a domain switching between char maps. If some kind of local net is created where people writing and speaking only some Cyrillic based language, then getting them type a mixed chars domain name would be a great anti-pattern. Provides nothing useful for the user and IMO can happily be disabled by default. That means, I propose to show the punycode for every domain that contains characters from different character sets. If this is for some reason rejected, my second best option is to assign colors to the different charsets used in a domain name and color each letter with the corresponding color. e.g. instead of black, if I mix Latin and Cyrillic, I'll see Latin in green and Cyrillic in red. If everything is same charset, then I will see normal black url text. If I hover the URL it will show a warning that mixed charsets are used.
Version: 50 Branch → 58 Branch
+ 1 I AM with you Alexander and I am very deluded from Firefox about closing comments to a security issue bugs and see no security has been implement from Firefox in this side. I think we will continue to see this vulnerability in the browser and I will continue to read from developers that is not a security risk and should be not fixed by the browser. Very sad experience. I am very sad Firefox user about this unfixed security issue!
but wasnt iirc multiple characters of different sets fixed and the bug which was closed for commenting iirc only for WHOLE SCRIPT confusables, meaning for example cyrillic only names that look like latin? like with the fake apple website which has the word apple spelt completely using cyrillic characters (russian, ukrainian etc) I personally think that at the very least for the three sets of greek cyrillic and latin, either all parts of the fomain are of the same set, or none. I mean there are greek and cyrillic TLDs so that isnt too much of an issue and why should someone use a cyrillic domain with a latin TLD, these are just a pain to type, a lot easier to just use a cyrillic TLD, same for greek.
The example I posted recently from Krebs on Security was two Cyrillic characters: xn--80a7a.com is U+0441 U+0430 ".com" which looks like ca.com. https://krebsonsecurity.com/2018/03/look-alike-domains-and-visual-confusion/
How is exactly Firefox supposed to tell between the malicious "ca.com with 'ca' in Cyrillic" and all the benign <cyrillic>.com domains that have been registered throughout the years, when Cyrillic TLDs did not exist (thanks ICANN), and are now being legitimately used in Russia? If the display of all <cyrillic>.com domains were forced to be in punycode, all the Russian users and owners of those domains would be discriminated. This does not mean that you cannot think of some security check in Firefox, possibly connected to the user's locale and preferred languages, but it's not so immediate; all in all, phishing is based on using valid domains for evil purposes, but this does not allow you to conclude that an entire type of domains is evil per se; it's the use that is malicious, not the domain or any similar domains, so security features should focus on detecting, reporting and blocking malicious uses, rather than on disrupting the Internet for non-Western users. (Another option would be to phase out <non-ASCII>.<ASCII> domains and say that they will be moved into equivalent <non-ASCII> TLDs by a certain date, and you are free to go to ICANN and propose this idea, but it would create so many marketing, indemnification and extra cost issues that it will never happen.)
The punnycode option should be set to true by default on all Firefox browser. This will be the first step to "solve" the security issue. After that I think Firefox should show differently punnycode domain with a different color, this because a unlocked computer can alow someone to change the default Firefox settings ... user think all is ok but the "show punnycode" disabled is very dangerous if you have no way for see the difference between a real domain and "a fake one". Someone can compromise Firefox settings and disable "show punnycode" so the next step is to send a fake link in the victim PC. Please fix all securty issue.
@Vittorio "Another option would be to phase out <non-ASCII>.<ASCII> domains and say that they will be moved into equivalent <non-ASCII> TLDs by a certain date" that's actually a good Idea. in CA business this kinda stuff happens all the time, so it would not be too weird in my opinon
(In reply to Alexander from comment #0) > +++ This bug was initially created as a clone of Bug #1332714 +++ > Firefox/58 > > This is a clone of Bug #1332714 because I couldn't comment on it for some > reason. Commenting was deliberately restricted, see https://bugzilla.mozilla.org/show_bug.cgi?id=1332714#c87 , because no new information or suggestions were added, people were just re-iterating previous points and "me too"-ing the importance of the issue. That's not what a bugtracker is for. Your new bug and its comment #0 (and some of the subsequent comments) are another example of this happening, because both your points have been suggested already on the main bug and were dismissed because things are not as simple as they might appear. > That means, I propose to show the punycode for every domain that contains > characters from different character sets. It's not clear if by domain you mean "including the TLD" or not - e.g. is <all-cyrillic>.com acceptable or not? What about <all-cyrillic>.ru or <all-cyrillic>.bg ? If the answer is "no", then you wouldn't adddress the `ca.com` spoof that has brought renewed attention to this issue. If the answer is "yes", then you're making a non-trivial number of domains display like unreadable trash for no real reason. Neither option really helps, and neither option is what other browsers have implemented. More generally, there are strict rules about script mixing as detailed in http://www.unicode.org/reports/tr39/#Restriction_Level_Detection . Both Chrome and Firefox use the 'highly restrictive' rules on their current release versions; Chrome has chosen to implement additional restrictions that are not outlined in that document or (to the best of my personal knowledge) standardized in some kind of cross-browser forum like whatwg, w3c, or any of the unicode-related groups. > If this is for some reason rejected, my second best option is to assign > colors to the different charsets used in a domain name and color each letter > with the corresponding color. e.g. instead of black, if I mix Latin and > Cyrillic, I'll see Latin in green and Cyrillic in red. If everything is same > charset, then I will see normal black url text. If I hover the URL it will > show a warning that mixed charsets are used. This has the same issues as your previous suggestion, but on top of that doesn't help people with various types of vision issues (e.g. colourblindness), might be abused for the confusion with e.g. EV marking in the URL Bar, and the "hover warning" won't help people who don't use a mouse (and thus can't access "hover warnings"), plus being generally undiscoverable. If you're concerned about this issue, feel you need an immediate solution, and don't use domains that use IDNA, by all means turn the relevant pref off in about:config ( network.IDN_show_punycode ), or install an add-on that highlights when a domain uses IDNA or mixed scripts (e.g. https://addons.mozilla.org/en-US/firefox/addon/idn-warner/ , which is the first relevant hit in my google search 'idn firefox extension', in no way implies my endorsement etc. etc., but looks like it would do the job). Because you cloned the original bug and thus every comment spams 70 people in the CC list, I'm restricting comments here too to avoid further wasting people's time by going over previously-proposed solutions again and again.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Restrict Comments: true
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.