Xudong Zheng

See: punycode phishing / homograph attacks They likely mean Unicode outside the ASCII range. Last I checked Firefox refuses to implement the "fix" for this type of attack because it is "culturally insensitive" and "treats English as a privileged language over other languages". This URL in Firefox should look like "apple.com": https://xn--80ak6aa92e.com/

I'm honestly surprised at Firefox's behavior here. I thought all of the browsers years ago identified homoglyph attacks and deployed defenses. For example, in Safari, this domain does render as https://www.xn--80ak6aa92e.com because Safari decided this was a homoglyph attack. My impression was all the browsers did this for any domain that used a homoglyph of a latin character, so why is Firefox failing?

Firefox users: be sure to set "network.IDN_show_punycode" to "true" in about:config. Test with the fake Apple domain https://www.xn--80ak6aa92e.com/ . See "Phishing with Unicode Domains" for more information: https://www.xudongz.com/blog/2017/idn-phishing/ .

> And even for well-known domains, https://www.xn--80ak6aa92e.com/ (currently still works in Firefox) How is it that this still works in Firefox? It's been fixed for years in all other major browsers. I'm seriously shocked that Firefox still allows IDN homograph attacks.

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=279099 or this site that looks like apple.com https://www.xn--80ak6aa92e.com/ regarding homographic or look alike character attacks. As an American only fluent in English I'm enormously more likely to encounter malicious content than content that is useful to me on internationalized domain names. To make this less likely you can set network.IDN_show_punycode true in about:config for firefox or in your profile directory you can create a user.js file and add this line. user_pref("network.IDN_show_punycode", true)

How does a U2F key even solve the problem of knowing that a website associates with a real identity? It may stop a phishing attack, but where do you get the initial trust to begin with? I think the issue is that we need to know that google.com can be shown to clearly be owned by Google, LLC, and not GoogleCo in a small African nation. (And also, presumably, that google.com is actually google.com, and not some weird substitutions in there like https://www.xn--80ak6aa92e.com/ which shows as apple.com on Firefox.) That's going to be the EV system or something like it, and it's inherently impossible to keep that in line with "the web's political values", if you describe those values as requiring that "anyone can get one". There will always be some justification that someone, somewhere, can find to call themselves something.

Domain names don't solve that either. For one tenth that cost, you can register stripeinc.net and get an SSL cert. Yay! Domain registration is available instantly for anyone, anytime, and it can be phished at least as easily as anything else. https://www.xn--80ak6aa92e.com/ looks pretty legit in Firefox.

This actually isn't true. A website like https://www.xn--80ak6aa92e.com/ won't show up as apple.com. Browsers don't allow Unicode rendering in the URL bar. Maybe IE is affected though. I haven't tested every browser. But it's a known security concern.

Browser shows https://www.xn--80ak6aa92e.com to me, Chrome on Android. What browser are you using that shows non-ascii with .com?

Latest Chrome and Safari shows that as https://www.xn--80ak6aa92e.com, no puny code

Firefox: open about:config, set network.IDN_show_punycode to true. Next time you open the page, the address bar will show https://www.xn--80ak6aa92e.com/ instead of https://www.apple.com/. Better yet, always type in or bookmark pages where you might enter sensitive information. I was surprised this was still an issue, as I heard about IDN homograph attacks years ago.

If you use a password manager, it most likely won't auto-fill apple.com's passwords on https://www.xn--80ak6aa92e.com/

Interesting. The apple.com one (https://www.xn--80ak6aa92e.com/) shows literally that text in Pale Moon (27.2), but shows "аррӏе.com" (Cyrillic text) in Chrome 57 and Firefox 51. Someone else's example that looks like "app.com" ( http://www.xn--80a6aa.com/) translates to the Cyrillic text, even in Pale Moon. I wonder if Apple's site is on a hard-coded blacklist in the browser, or if every update includes the top-1000 list, or something? I remember reading about issues with Unicode domains years ago, though. It surprises me that something hasn't been figured out by this point. One mitigation that I remember being discussed was coloring characters from different scripts in different colors, to make variant characters more obvious.

On Debian 9.0 (64-bit), with defaults: Not affected: - Chromium Version 57.0.2987.133 Affected: - Chrome Version 57.0.2987.133 - Firefox ESR 45.8.0 - Tor Browser 6.5.1 (based on Mozilla Firefox 45.8.0) tested with https://www.xn--80ak6aa92e.com/ -> https://www.apple.com/

Someone created apple.com ... https://www.xn--80ak6aa92e.com/

>A closer link at the link, however, shows that the site is not the genuine one. In fact, ķeepass[.]info —at least when it appears in the address bar—is just an encoded way of denoting xn--eepass-vbb[.]info, which it turns out, is pushing a malware family tracked as FakeBat. Combining the ad on Google with a website with an almost identical URL creates a near perfect storm of deception. “Users are first deceived via the Google ad that looks entirely legitimate and then again via a lookalike domain,” Jérôme Segura, head of threat intelligence at security provider Malwarebytes, Back in 2017, Google Chrome 59 supposedly fixed the Punycode phishing attack. E.g. story: https://www.engadget.com/2017-04-17-google-chrome-phishing-unicode-fla… Maybe a dedicated criminal studied the Chromium source code that checks Punycode and noticed a flaw where it would allow 'ķ' in place of 'k' ??? https://www.xn--80ak6aa92e.com/ --> fake "apple.com" triggers phishing warning https://xn--eepass-vbb.info/ --> fake "ķeepass.info" does not trigger warning

Sure, but that's just more reason to use HTTPS across their entire domain and would help prevent users from being phished as easily. If I enter "apple.com" I expect all links on that page to point me to the correct location. A MITM attack from a non-HTTP page could easily alter the page and link me to https://www.xn--80ak6aa92e.com/login instead.