1405963 - IDN spoofing is still easy with same-script homoglyphs

Status: NEW

(Firefox :: Site Identity, defect, P3)

Description

[Tristan Bourvon]

A lot of progress has been made towards reducing IDN spoofing risks (notably in https://bugzilla.mozilla.org/show_bug.cgi?id=1399939).

However, many IDN spoofings are still possible using same-script homoglyphs, in particular from the Cyrillic script.

I believe some ad-hoc rules should be added (like https://bugs.chromium.org/p/chromium/issues/detail?id=683314#c23) to reduce risks even further.

All other major browsers (I've personally tested Chrome and Safari) display punny-code instead of the rendered IDN for https://аррӏе.com/, so that users know that this is not the Latin version. I think this is the correct behavior and FF should probably do the same.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

I tend to agree that there is a problem. Even though Gerv has a point that the registrars should fix this, it doesn't seem like we can force them to take action sooner.
At this point it's quite easy for the user to be confused by non-ascii characters in the URL bar.
I believe chrome's fix would be a step forward, and I'd also like to see some kind of visual indication in the URL bar when the current domain is actually IDN. At the very least, we should add the punycode domain name to the doorhanger.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: For non-ASCII domains, add the punycode domain name to the identity popup to help clarify what domain is really being visited

Here's a simple patch that aims to add the punycode domain to the identity doorhanger. While this doesn't fully solve things (how many users ever look here at all?), it at least provides a relatively straightforward way to check for such spoofs in the event of any uncertainty. I'll attach a couple of screenshots showing the kind of results this gives.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: identity panel for https://аррӏе.com/ (Cyrillic spoof) with the above patch

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: similarly for an insecure cyrillic-script domain (http://www.ссср.com/, where "ссср" is cyrillic)

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: in contrast, nothing is added to the panel for the ASCII domain cccp.com

Comment 6

[Jonathan Kew [:jfkthame]]

Comment on attachment 8916020 [details] [diff] [review]
For non-ASCII domains, add the punycode domain name to the identity popup to help clarify what domain is really being visited

WDYT - does this seem like a worthwhile tweak? Should we attempt to review & land something along these lines? (Maybe UX folk will have better ideas for how to present it...)

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 8916020 [details] [diff] [review]
For non-ASCII domains, add the punycode domain name to the identity popup to help clarify what domain is really being visited

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

This is what I had in mind. The doorhanger looks great.
I don't know if doing this to getEffectiveHost is the best way of implementing this. I would expect it to return just one domain string, not two.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to Valentin Gosu [:valentin] from comment #7)
> I don't know if doing this to getEffectiveHost is the best way of
> implementing this. I would expect it to return just one domain string, not
> two.

Yeah, I agree it seems a bit hacky. Mostly I was looking for a simple way to patch things so we could see how it looks in practice, and this avoided adding an extra element to the XUL or anything like that. But I'm sure we can find a cleaner way to implement it.

Comment 9

[Johann Hofmann [:johannh]]

Jonathan, are you working on this (in which case it's a P1 with you as the assignee) or should I put it on P3?

Comment 10

[Gervase Markham [:gerv]]

While I can understand the motivation, I'm not in favour of this change, for a couple of reasons.

Firstly, people don't look at the doorhanger when visiting domains they think they know. So this isn't going to save anyone; it feels more like a "cover your behind" move than something that will actually be effective.

Secondly, punycode is an on-the-wire format, not a display format. I know it's been (ab)used as an error indication for dodgy domains, because it's the only unambiguous version of the name we have, but to most people it still looks like line noise and they don't know what it is. It's scary, and that's sort of the intent. So, putting it in the doorhanger for every IDN domain starts to make IDN domain names second-class citizens, which is something we've worked really hard to avoid when setting policy in this area. Our goal is that Russian people should be allowed to use their script in domain names in just the same way that English people can.

So what can we do? We are moving to Highly Restrictive, which helps, and we are trying to use additional script properties to rein in the abuse of combining marks, which will also help. And I'm not against additional ad-hoc banning heuristics if a) we can cover a good class of problems with a simple rule, and b) we can get them agreed with other browsers, rather than every browser implementing their own version of "Panic!". We have a good communication channel with Chrome on this, which is a start. 

Gerv

Comment 11

[Valentin Gosu [:valentin] (he/him)]

My reason for suggesting this is that in the case of https://аррӏе.com/ it is difficult even for me to identify if I'm on the actual apple.com or not.
I agree that this is not a solution for the IDN problem, but we do need to make the origin more visible in the UI.
I'm happy with any other solution which addresses this issue.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: For non-ASCII domains, add the punycode domain name to the identity popup to help clarify what domain is really being visited

Here's a somewhat less hacky implementation of the idea; this one puts the punycode host into a separate label element so that we can use color to make it more noticeable.

Comment 13

[Jonathan Kew [:jfkthame]]

FWIW, I tend to agree with Gerv's concerns in comment 10; doing this with the doorhanger is certainly not a full solution. But I'm not entirely against it, either; the site-identity doorhanger is technical detail that most users will never see, but for those who are aware of it and do want to explicitly confirm a site's identity, I think exposing the punycode host in addition to the IDN is a reasonable thing to do, and IMO it doesn't significantly hurt the non-Western web (for the same reason as it's not very effective as phishing protection for general users: they'll never see it).

Anyway, I'm just putting the patch out there for consideration as a low-risk option that I think has some (limited) value.

Comment 14

[:Gijs (he/him)]

Comment on attachment 8916568 [details] [diff] [review]
For non-ASCII domains, add the punycode domain name to the identity popup to help clarify what domain is really being visited

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

I share Gerv's concerns here. I think there are some technical things that I would want to change in this patch if there was agreement the general direction was wanted, so I'm clearing review based on both of those counts. For further reviews, please ask :johannh, who knows the site identity panel at least as well as me, and isn't on PTO for the rest of October (starting Thu). :-)

(In reply to Jonathan Kew (:jfkthame) from comment #13)
[slightly rearranging this comment for priority/reading ease]

> Anyway, I'm just putting the patch out there for consideration as a low-risk
> option that I think has some (limited) value.

I understand, and I like "suggestions as patches" generally, but it feels like there must be some better thing that we can do here than this approach - one that can hopefully help "normal" users who don't know about the identity popup, and only 'activates' on 'phishy' domains rather than anything that happens to use IDN.

I also, on a general level, think that some people (with what I am sure are the best of intentions) overestimate the impact of these attempts at phishing. People fall for much less convincing phishes, and technically minded folks (should) already know not to click links but to use bookmarks or their own input to access important websites like their bank / apple.com / whatever. *If* these phishing attacks were ever used in practice, they would be on safebrowsing and similar blocklists within a very short space of time -- just like the "less effective" attempts of "apple-security.afdgsdvsdfgsdfg.blogspot.com" or whatever the latest techniques are. So on the whole, I just remain unconvinced that these gaps are a realistic threat vector that we need to scramble to address.

> the site-identity doorhanger is technical detail that
> most users will never see, but for those who are aware of it and do want to
> explicitly confirm a site's identity, I think exposing the punycode host in
> addition to the IDN is a reasonable thing to do, and IMO it doesn't
> significantly hurt the non-Western web (for the same reason as it's not very
> effective as phishing protection for general users: they'll never see it).

I don't think "X will help because of Y, but X will also not hurt, because of the same Y" is a very convincing argument.

If people genuinely thought that this type of checking was helpful, someone could (maybe should?) write a trivial webextension that simply displayed a big red notification icon whenever they were on an IDN domain.

::: browser/base/content/browser.js
@@ +7707,5 @@
>      try {
>        host = this.getEffectiveHost();
> +      // If the displayed host is not the same as its raw ASCII value
> +      // (i.e. it's an IDN), we'll also display the punycode version.
> +      if (host != this._uri.host) {

Hrmpf, feels like we should rather expose something on the nsIURI rather than hand-checking this stuff, but I guess it works for now.

::: browser/themes/shared/controlcenter/panel.inc.css
@@ +205,5 @@
> +  color: #cc0000;
> +}
> +
> +.identity-popup-host-punycode::before {
> +  content: '(';

This may need to be localizable, so I don't think this is the right approach.

Comment 15

[Jonathan Kew [:jfkthame]]

Fair enough.

ISTM this is primarily a UX problem, and we haven't really figured out yet what a useful solution will look like. The suggestion to put extra info in the doorhanger avoided that to some extent (by putting the addition into secondary UI that is only displayed if the user explicitly goes looking for it), but this also greatly limits its usefulness.

Comment 16

[Johann Hofmann [:johannh]]

Ok, let's put this in the backlog for now.