[UA-discuss] Re : And now about phishing...

Fri Apr 21 21:45:08 UTC 2017

Hi Asmus,

If I understood correctly, it’s a good approach, but it’s definitely not the one for average user.

First of all, average user have a problem to see the difference between http and https. Average owner of domain name usually don’t know what SSL is.

I agree with you that this suggestion is better than make IDNs second-class URLs, but in my opinion, it’s not for average user.

And in this case, you just assume that “fake websites” must have certificate? 

And yes, I admit, I don’t know how to solve this… 

Cheers,

Dusan

From: ua-discuss-bounces at icann.org [mailto:ua-discuss-bounces at icann.org] On Behalf Of Asmus Freytag
Sent: Friday, April 21, 2017 7:05 PM
To: ua-discuss at icann.org
Subject: Re: [UA-discuss] Re : And now about phishing...

On 4/21/2017 2:50 AM, Dusan Stojicevic wrote:

More on Mozilla>

https://wiki.mozilla.org/IDN_Display_Algorithm

FWIW, I think that this is a problem on which UASG must react somehow.

@Asmus: this phishing issue is not new. We were speaking about it 2 years ago. And yes, it’s starting to create a big problem.

All,

confusables spoofing is *not* limited to cross-script homoglyphs, although the Latin/Cyrillic case is particularly egregious.

This kind of defense shown below works even for non-homoglyph attacks, such as "gooogle" or similar typos that may be hard to spot with perfect reliability. More can be done in that direction, without making IDNs second-class URLs.

For the cross script case, the registries could do a lot more, and we are definitely going to do more in the root.

On my system I get this, when I connect to "apple.com":

and this, for the "fake" (https://www.аррӏе.com/)

Arguably, the lock should change color if there's no owner information
present, to give a better warning than just the absence of an identification.

A./

@Dusan: I know that this phishing issue is not new, I've known about that one for way longer than just two years (and for longer than I've been active in the IDN area).

Cheers,
Dusan

From: ua-discuss-bounces at icann.org <mailto:ua-discuss-bounces at icann.org>  [mailto:ua-discuss-bounces at icann.org] On Behalf Of Vittorio Bertola
Sent: Friday, April 21, 2017 11:04 AM
To: ua-discuss at icann.org <mailto:ua-discuss at icann.org> ; Asmus Freytag  <mailto:asmusf at ix.netcom.com> <asmusf at ix.netcom.com>
Subject: Re: [UA-discuss] Re : And now about phishing...

Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf at ix.netcom.com <mailto:asmusf at ix.netcom.com> > ha scritto:

If you think about it, the following recommendation at the end is anathema to "Universal acceptance":

"Zheng is encouraging Firefox users to limit their exposure to the bug by going to the browser’s about:config settings and setting network.IDN_show_punycode to true. By doing this Firefox will always display IDN domains in its Punycode form, something that should make it easier to identify malicious domains, the researcher claims."

If you do that, you implicitly assume that only the "non-IDN" links are "real", in other words, you assume an English-only environment. (When stuff is displayed as punicode, you usually can't tell what domain it is, except you can guess for some European ones with very few special characters, but you can't be sure unless the Unicode form is at least also displayed, which I think is not what that config change means).

Hello,

excuse me if I jump into a discussion having just joined the list, but this issue is really troubling me for at least two reasons.

First, many news sources are now filling up with calls and guides for disabling IDNs in browsers altogether, which is a death call for universal acceptance. It all started with this horrible post by Wordfence's CEO, basically equating IDNs to an instrument conceived for phishing:

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

It would be really good if anyone knew him and could have a chat with him, maybe even convince him to help spreading a better view of the issue.

Secondly, browser makers are now reacting in opposite ways:

1) Microsoft's browser (AFAIK) will enable or disable the display of Unicode in the URL bar depending on the operating system's language;

2) Google's browser, with a newly released patch, will not display Unicode IDNs in ASCII TLDs if the IDNs are whole-script confusables ( https://codereview.chromium.org/2683793010 );

3) Mozilla's browser will explicitly always display Unicode IDNs regardless of whether this may be used for phishing ( https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ  <https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ> and https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 ). However, multiple online sources are now advising people to use a Firefox configuration option that allows to disable the display of IDNs altogether.

(Don't know about Apple, Opera and others.)

As you see, this is going to hamper the usability of IDNs in URLs and, even worse, make it entirely unpredictable, depending on the user's browser choice.

The only real solution to this is that all registries treat whole script confusables as variants, so that they cannot be registered to anyone different than the owner of the equivalent ASCII domain. Unicode TR-39 allows to do this programmatically. However, I just checked the proposed draft IDN guidelines that are currently undergoing public consultation at ICANN:

https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en.pdf

At point 16, they say that the registry "may" do this, but that should really be a "must". If this does not happen, there will be more of these situations and the risk that all the Western world will then disable IDNs in URLs for good is quite significant. 

I think that this group could do several useful things:

a) promote a better public understanding of the issue, countering the trend that "IDN URLs are for phishing";

b) encourage browser makers to elaborate a common approach;

c) push for ICANN and the registries to free the Internet from whole-script confusables.

Regards,

-- 

Vittorio Bertola
Research & Innovation Engineer 

Cell:

+39 348 7015022

Skype:

in-skype-ox at bertola.eu <mailto:in-skype-ox at bertola.eu> 

Email:

vittorio.bertola at open-xchange.com <mailto:vittorio.bertola at open-xchange.com> 

Twitter: @openexchange <http://twitter.com/openexchange>  - Facebook: OpenXchange <https://www.facebook.com/OpenXchange>  - Web: www.open-xchange.com <http://www.open-xchange.com> 

Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Directors: Frank Hoberg, Martin Kauss

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> 

Virus-free.  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> www.avast.com 

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4308 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/image001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3907 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/image002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 76848 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/image003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 65068 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/image004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 6064 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170421/78ab32ed/image005.png>