[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26634: 26.0.50; The network security manager doesn't understand IDNA
From: |
Robert Pluim |
Subject: |
bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains |
Date: |
Fri, 13 Apr 2018 17:03:37 +0200 |
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> If you type `M-x eww RET https://аррӏе.com RET', the NSM will then say:
>>>
>>> "certificate host doesn't match hostname"
>>
>> Hm... Now Emacs refuses to load that URL completely...
>
> OK; I've now fixed recent breakages so that we can access
> https://аррӏе.com again.
>
> Now the question is... what do we do about this in the network security
> manager.
>
> If you go to that domain in Firefox, for instance, it won't say that
> there's anything wrong with it... because it isn't. It's a totally
> normal domain name consisting of ASCII characters and a CYRILLIC SMALL
> LETTER PALOCHKA instead of the L.
>
Thatʼs not what you have there. The first component of your FQDN is
100% cyrillic. Did you mean <https://appӏe.com> ? (FWIW, chrome is
supposed to detect the 100% cyrillic case, but doesnʼt as far as I can
tell)
> `puny-highly-restrictive-domain-p' is not triggered for the domain, so
> eww doesn't signal anything wrong with it, either.
>
> So... Do we say "fine, this is all fine" or do we ... do something?
> :-) Opinions welcome.
In emacs-26, when I try eww on https://appӏe.com, I get
Loading https://xn--appe-xre.com/...
which is already an indication that something fishy is going on.
Robert