Opened 3 years ago

Last modified 5 weeks ago

#21961 needs_information enhancement

should torbrowser enable network.IDN_show_punycode by default?

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201912
Cc: ikurua22, mcs, brade, qbi, intrigeri, anonym, arthuredelstein, floweb, ux-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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/

Child Tickets

Change History (21)

comment:1 Changed 3 years ago by gk

Cc: ikurua22 added

#21976 is a duplicate.

comment:2 Changed 3 years ago by cypherpunks

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

comment:3 Changed 3 years ago by arthuredelstein

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.

comment:4 Changed 3 years ago by mcs

Cc: mcs added

comment:5 Changed 3 years ago by mcs

Cc: brade added
Summary: shoult torbrowser enable network.IDN_show_punycode by default?should torbrowser enable network.IDN_show_punycode by default?

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

comment:6 Changed 3 years ago by cypherpunks

Status: newneeds_review

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.

comment:7 Changed 3 years ago by mrphs

Priority: MediumImmediate

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

comment:8 Changed 3 years ago by mrphs

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/

comment:9 Changed 3 years ago by qbi

Cc: qbi added

comment:10 Changed 3 years ago by intrigeri

Cc: intrigeri anonym added

comment:11 Changed 2 years ago by cypherpunks

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.

comment:13 Changed 23 months ago by y2875095

TBB should prevent phishing.

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

comment:14 Changed 23 months ago by y2875095

Severity: NormalMajor

comment:15 Changed 22 months ago by arthuredelstein

Cc: arthuredelstein added

comment:16 Changed 14 months ago by gk

Cc: floweb added

#27887 is a duplicate.

comment:17 Changed 10 months ago by cypherpunks

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

why not implement this first then think about the default?

comment:18 Changed 7 weeks ago by adrelanos

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:

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.

comment:19 Changed 6 weeks ago by sysrqb

Cc: ux-team added
Keywords: TorBrowserTeam201912 added
Priority: ImmediateHigh
Severity: MajorNormal
Status: needs_reviewneeds_information

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)

comment:20 Changed 6 weeks ago by Thorin

The downside is it will display legitimate IDN's punycoded, which might be undesirable for users of non-latin alphabets. From a usability perspective, this should be a no go: but maybe if could be flipped with privacy.spoof_english - but that's mixing privacy and security up. If anything, it would fit better being flipped in the slider.

Personally: I think this is an end-user problem, and there is no magic solution: of course better solutions upstream or at the domain registering level etc are always welcome.

comment:21 Changed 5 weeks ago by adrelanos

Chrome and other browsers fixed this vulnerability. Just Firefox refused.

Note: See TracTickets for help on using tickets.