should torbrowser enable network.IDN_show_punycode by default?

Firefox and torbrowser do not show punycodes by default.

The attack vector is discussed here, including a demo:

https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

added TorBrowserTeam202006 component::applications/tor browser owner::tbb-team priority::high severity::normal status::needs-information type::enhancement labels

#21976 (moved) is a duplicate.

Trac:
Cc: N/A to ikurua22

depending on how fast you want to address this you might also wait for the final decision in the upstream ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1332714

Another possibility is to show a warning when a homographic domain is displayed. Showing a punycode by default has the disadvantage that it becomes unreadable for non-latin domains.

Trac:
Cc: ikurua22 to ikurua22, mcs

I wonder where this is now being discussed on the Mozilla side. Comments on the Bugzilla bug were closed after an FAQ was published (which I read), but now the FAQ is gone. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1332714#c78

Trac:
Cc: ikurua22, mcs to ikurua22, mcs, brade
Summary: shoult torbrowser enable network.IDN_show_punycode by default? to should torbrowser enable network.IDN_show_punycode by default?

Answer: No.

Everything was discussed on BMO and closed.

The discussed attack vector was phishing (sec-low). And it is the user's responsibility.

But TBB-specific attack is DNS-spoofing by the exit node. And it should gain more priority.

Trac:
Status: new to needs_review

Bumping up the priority as our users can be potentially actively exploited with this new phishing method.

Trac:
Priority: Medium to Immediate

This is how google responded to the homograph attack: https://www.chromium.org/developers/design-documents/idn-in-google-chrome

PoC and how it looks on Tor Browser => https://www.аррӏе.com/

Trac:
Cc: ikurua22, mcs, brade to ikurua22, mcs, brade, qbi

Trac:
Cc: ikurua22, mcs, brade, qbi to ikurua22, mcs, brade, qbi, intrigeri, anonym

The fact that Chrome/Chromium has this mitigated, while Firefox has stubbornly refused to change their behavior, calling it someone else's problem, is one of the many reasons that people (rightfully) criticize Firefox and its devs for having poor security. Imagine how easy it would be for an administrator of a dissident website, or the code repository website for a critical or popular program (such as Tor?) to be compromised.

Perhaps only enable the punycode feature when not on the lowest security level? The description in the browser security slider could say "Domains with unicode may not display properly", with the mouseover text saying "Characters that can be used to create a domain that looks identical to an existing domain will be displayed differently".

I'm going to have to require all the important members of a website I own to log in exclusively using client certificates, since they will only work on the correct domain. I would much rather if I did not have to do something which has an impact on my users just because poorly-secured browsers insist on this being someone else's problem.

Everything messed https://bugzilla.mozilla.org/show_bug.cgi?id=1380617

TBB should prevent phishing.

Browsers should format address bar like: https://www.xn--e1awd7f.com/ (displayed as: epic.com)

Trac:
Username: y2875095

Trac:
Username: y2875095
Severity: Normal to Major

Trac:
Cc: ikurua22, mcs, brade, qbi, intrigeri, anonym to ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein

#27887 (moved) is a duplicate.

Trac:
Cc: ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein to ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein, floweb

network.IDN_show_punycode should be on when security level is set to safest.

why not implement this first then think about the default?

A good title would also be very hard to notice Phishing Scam - Firefox / Tor Browser URL not showing real Domain Name - Homograph attack (Punycode).

https://www.xn--80ak6aa92e.com/ shows up as apple.com. Even including green SSL lock. But it is a demonstration, proof of concept of a phishing side by a security researcher.

https://www.xn--80ak6aa92e.com/ shows up as https://www.apple.com.

Screenshot:

https://www.xudongz.com/static/942a1d48cb68b8678e2713249d1ae7ceaf9fa4c39767562a8caf6cc856626160.png

References:

• https://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html
• https://www.xudongz.com/blog/2017/idn-phishing/

I can’t even find Mozilla’s rationale for being adamant about this. 3 years ago they wrote:

We now have an FAQ which makes our position clear: https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ

Nowadays this wiki page is empty (links to another empty wiki page).

Please consider setting network.IDN_show_punycode to true by default.

I think the status of this ticket needs_review may be wrong.

We should think about and understand the usability implications of simply flipping the pref. How do other browsers handle this and what should the user do when they see the url rewritten? How do we make sure people actually notice something is (possibly) wrong while not scaring them or confusing them when it is a false-positive?

(To be clear, I haven't investigated this at all, these are simply questions I have from skimming this ticket)

Trac:
Keywords: N/A deleted, TorBrowserTeam201912 added
Cc: ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein, floweb to ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein, floweb, ux-team
Status: needs_review to needs_information
Priority: Immediate to High
Severity: Major to Normal