bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

If you type `M-x eww RET https://аррӏе.com RET', the NSM will then say:

"certificate host doesn't match hostname"

That's an IDNA domain that expands to https://www.xn--80ak6aa92e.com/,
which does have a valid certificate, so this is a bug.

If instead say `M-x eww RET https://www.xn--80ak6aa92e.com/ RET' you get
no warnings.


In GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-04-13 built on stories
Repository revision: 4e77ff0d45b88cade7836c01344cd8d892adfde8
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.7 (jessie)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

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...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

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.

`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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Robert Pluim]

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

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Thatʼs not what you have there. The first component of your FQDN is
> 100% cyrillic.

My FQDM?  "gnus.org"?  That's not very cyrillic.  :-)

> Did you mean <https://appӏe.com> ?

No, I meant https://аррӏе.com which is a totally different domain.  :-)

Hm...  Oh, that's the 100% cyrillic one.  :-)  This is so confusing.

So eww definitely does the right thing with the mixed-script аррӏе.com,
and I guess there's nothing to be done with the 100%-cyrillic case...

> (FWIW, chrome is supposed to detect the 100% cyrillic case, but
> doesnʼt as far as I can tell)

What does Chrome do with that URL?

Oh, I've got Chromium here, so I can just test...

It displays https://xn--80ak6aa92e.com/ in the address bar.  Which
is...  I guess...  a choice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>> Did you mean <https://appӏe.com> ?
>
> No, I meant https://аррӏе.com which is a totally different domain.  :-)
>
> Hm...  Oh, that's the 100% cyrillic one.  :-)  This is so confusing.
>

Fun, isnʼt it? Can we go back to 7-bit ASCII please?

> So eww definitely does the right thing with the mixed-script аррӏе.com,
> and I guess there's nothing to be done with the 100%-cyrillic case...
>
>> (FWIW, chrome is supposed to detect the 100% cyrillic case, but
>> doesnʼt as far as I can tell)
>
> What does Chrome do with that URL?
>
> Oh, I've got Chromium here, so I can just test...
>
> It displays https://xn--80ak6aa92e.com/ in the address bar.  Which
> is...  I guess...  a choice.

I donʼt mind that. Itʼs better than displaying the homograph.

Robert

bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>> It displays https://xn--80ak6aa92e.com/ in the address bar.  Which
>> is...  I guess...  a choice.
>
> I donʼt mind that. Itʼs better than displaying the homograph.

Well...  If you have an all-Cyrillic URL, then you should be able to
handle that as a normal domain, otherwise all this IDNA stuff is just
nonsense, and we'll never leave ASCII domains.  Firefox does the same as
Emacs currently does, and Chrome doesn't.

So I think I'll close this bug report and we can revisit the issue if an
industry "best practice" is ever established.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#26634: [Lars Ingebrigtsen] Re: bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains

[Lars Ingebrigtsen]

-------------------- Start of forwarded message --------------------
From: Lars Ingebrigtsen <larsi@gnus.org>
Subject: Re: bug#26634: 26.0.50; The network security manager doesn't understand IDNA domains
Date: Sun, 22 Jul 2018 13:04:44 +0200

Ted Zlatanov <tzz@lifelogs.com> writes:

> Suggestion: what if we used IDNA and highlighting if multiple scripts
> are mixed in any segment of the DNS path (a "word" in the syntax)? And a
> tooltip explaining the problem? That would make it clear to the user.

You mean in the eww title bar?  Yes, that would make sense...

> It would also be potentially beneficial in Dired and prog-mode. Here I
> would again flag any mixed scripts in a word.

Hm...  well, the security implications of having a mixed-script file
name are different from mixed-script domain names.  

> The same approach might be nice in `list-packages' in case someone
> malicious pushes out packages with confusables in the name. Here the
> check would flag anything non-ASCII.

That does sound useful.

> WDYT? A minor mode? Or maybe it exists already?

Not that I know of.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no
-------------------- End of forwarded message --------------------