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

On 4/18/17 2:29 AM, Gervase Markham wrote:

>> The word "fake" is probably an inpracise word to use, but in the
>> context that the domain name as registered is perporting to be
>> another domain name it is not; this is fake. The SSL provider;
>> LetsEncrypt in this case seems to not be able to ensure with browsers
>> that there is a clear destinction between the two names of the domain
>> certified by the CA.
>
> Neither browsers nor CAs have a database of all domain names, such that
> they can see that one is visually confusable with another. Registries
> have this data, and it is their responsibility to deal with this problem.

[As much as I hate to wade into this...]

Hmm. One thing browsers do have is the user's browsing history.

Half-baked thought for an imperfect mitigation:

When visiting a page, compute the normalized version domain, and see if 
that exists as a history entry. If the entry exists, display the 
punycode version of the domain. Otherwise, display the unicode version 
of the domain.


That makes it more difficult to trick an existing user of a site. If 
I've previously visited epic.com (ascii), visiting xn--e1awd7f.com will 
show xn--e1awd7f.com instead of еріс.com (cyrillic). But does nothing 
for attacks against domains a user might recognize but hasn't visited.

To handle bz's case of two non-ascii domains that are homographs of each 
other, I think you'd need to store the normalized domain in history too?

Bah, but visiting one such homograph would then cause both to display as 
punycode (as both history entries exist). So the history check would 
need to be a little more complex, to see which is the oldest site in the 
user's history. (If the oldest site is the fake site, the user is 
screwed for a while.)

So, I dunno. I'm sure there are other issues too. But maybe some kind of 
imperfect mitigation (perhaps not this one) is better than nothing?

Justin
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security