Re: Unicode domain names issue (Encrypting a "fake" domain name)
Martin Heaps <[email protected]> Wed, 19 Apr 2017 06:45:24 -0700 (PDT)
| Newsgroups | gmane.comp.mozilla.security |
|---|---|
| Message-ID | <[email protected]> |
I have been away for a few days, hence I would have added this below clarifier earlier: My issue is NOT with the character sets used or the ambiguity of these character sets, but is with the Browsers complete lack of ability in telling the human user that epic.com !== epic.com at any point short of opening up and readng the core TLS certificate itself. Reading the certificate is relatively simple (albeit 3-4 clicks) for Firefox but it's a hidden away aspect on Google Chrome, where the user needs to know 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 "output" name rather than the "raw" name of the website. THIS is the issue I am taking, and feel that should be fixed by browsers, by certificate providers and all parties in between. 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 simply 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: https://www.imageupload.co.uk/images/2017/04/19/chrome-epic-dot-com.png https://www.imageupload.co.uk/images/2017/04/19/chrome-epic-dot-com2.png https://www.imageupload.co.uk/images/2017/04/19/Firefox-epic-dot-com.png https://www.imageupload.co.uk/images/2017/04/19/Firefox-epic-dot-com3.png https://www.imageupload.co.uk/images/2017/04/19/Firefox-epic-dot-com2.png Thanks