Unicode domain names issue (Encrypting a "fake" domain name)

I was led today to this article - https://www.wordfence.com/blog/2017/04/ch=
rome-firefox-unicode-phishing/ - about the domain name 'www.epic.com' which=
 can be written using unicode as 'www.xn--e1awd7f.com' to make a fake websi=
te look exactly like the URL of the real website.

There is a work around in Firefox for this, but possibly more seriously:

LetsEncrypt has a valid encryption certificate for the fake domain, and in =
Firefox the domain certificate (when clicking on the padlock icon to view t=
he drop down box) still shows the processed unicode URL rather than the "ra=
w" URL (showing that the Encryption certificate is for "epic.com" rather th=
an "xn--e1awd7f.com" which is the domain given to LetsEncrypt).

This issue is clearly quite serious that certificate names can be manipulat=
ed to look like other names in certain situations, further undermining the =
value of the certificate as an authenticity check.=20

I would like this post to be a warning, and a sharing of this information, =
however the issue may well lay at the hands of browsers, but Certificate Au=
thorities should have a premise with Browsers that their certificate addres=
ses can and should only be shown in a set character set and never ever "int=
errepted" by the browser.=20

Article date: 14th April 2017.


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

- https://www.xudongz.com/blog/2017/idn-phishing/

- https://www.reddit.com/r/netsec/comments/65csdk/phishing_with_unicode_dom=
4/17/2017 2:38:16 PM
mozilla.dev.security 611 articles. 0 followers. Post Follow

3 Replies

Similar Articles

[PageSpeed] 32

Sorry;  "interrepted" should be "interpreted" .
4/17/2017 2:41:20 PM
I have been away for a few days, hence I would have added this below clarif=
ier earlier:=20

My issue is NOT with the character sets used or the ambiguity of these char=
acter sets, but is with the Browsers complete lack of ability in telling th=
e human user that epic.com !=3D=3D epic.com at any point short of opening u=
p and readng the core TLS certificate itself.=20

Reading the certificate is relatively simple (albeit 3-4 clicks) for Firefo=
x but it's a hidden away aspect on Google Chrome, where the user needs to k=
now where to find the certificate to reach it, rather than just exploreing =
and clicking suitable looking buttons (As seems to be with firefox Browser)=

Some examples using the epic.com domain name; showing that ALL views of the=
 security of the website short of viewing the full cerificate output the "o=
utput" name rather than the "raw" name of the website.=20

THIS is the issue I am taking, and feel that should be fixed by browsers, b=
y certificate providers and all parties in between.=20

I have NO issue with the character set of the certificate or the character =
set of the URL, this does not need to use the data held by registrars but s=
imply a patch on the browsers to note that:

- A certificate for "xn--e1awd7f.com" can be interpreted as "epic.com"

Some screen shots of the core issue, please review:=20







4/19/2017 1:45:24 PM
A possible solution is one that I envisage has the following practical effe=

That if the name can appear valid in another character set (as xn--e1awd7f.=
com can be epic.com, and russian characters can be used for latin character=
s, etc.) that the specific name the certificate is for is detailed on the B=
rowser as exampled in my edited screen shots below.=20

Please review this possible approach in clarifying the exact nature of whic=
h URL is being certified by a TLS certificate.=20



4/19/2017 1:56:10 PM