GNU bug report logs -
#26634
26.0.50; The network security manager doesn't understand IDNA domains
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Mon, 24 Apr 2017 03:14:02 UTC
Severity: normal
Tags: fixed
Found in version 26.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26634 in the body.
You can then email your comments to 26634 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Mon, 24 Apr 2017 03:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 24 Apr 2017 03:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Fri, 13 Apr 2018 13:19:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Fri, 13 Apr 2018 14:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Fri, 13 Apr 2018 15:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Fri, 13 Apr 2018 15:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Fri, 13 Apr 2018 15:39:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Robert Pluim <rpluim <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Sun, 15 Apr 2018 14:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 26634 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Apr 2018 14:00:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
26634 <at> debbugs.gnu.org and Lars Ingebrigtsen <larsi <at> gnus.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Apr 2018 14:00:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 14 May 2018 11:24:05 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 22 Jul 2018 11:07:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26634
; Package
emacs
.
(Sun, 22 Jul 2018 11:37:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 26634 <at> debbugs.gnu.org (full text, mbox):
-------------------- Start of forwarded message --------------------
From: Lars Ingebrigtsen <larsi <at> 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 <at> 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 --------------------
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 20 Aug 2018 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 244 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.