GNU bug report logs - #13374
24.?; open-gnutls-stream insecurity

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13374 in the body.
You can then email your comments to 13374 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Oleksii Shevchuk <alxchk <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.?; open-gnutls-stream insecurity
Date: Mon, 07 Jan 2013 12:20:45 +0200

Hi list!

open-gnutls-stream wrapper doesn't pass :verify-hostname-error t
:verify-error t to gnutls-negotiate. So MitM is possible when you use
gnus and other packages. 

Even with :verify-hostname-error t :verify-error t gnutls-negotiate
doesn't produce error with selfsigned CA certificate, when :type
'gnutls-x509pki passed.

I use next in my .gnus:

(defun open-gnutls-stream (name buffer host service)
  (gnutls-negotiate :process (open-network-stream name buffer host service)
                    :hostname host
                    :verify-hostname-error t :verify-error t))

Works for me.

// ----

In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2013-01-06 on BlackICE
Bzr revision: cyd <at> gnu.org-20130106025857-h1wkwx5cwvekj4l1
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --libdir=/usr/lib64
 --disable-dependency-tracking --program-suffix=-emacs-24-vcs
 --program-transform-name=s/emacs-[0-9].*/emacs-24-vcs/
 --infodir=/usr/share/info/emacs-24-vcs
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-crt-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../lib64
 --with-gameuser=games --without-compress-info --without-hesiod
 --without-kerberos --without-kerberos5 --with-gpm --with-dbus
 --with-gnutls --with-xml2 --without-selinux --with-wide-int
 --with-sound --with-x --without-ns --without-gconf --with-gsettings
 --without-toolkit-scroll-bars --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --without-imagemagick --with-xft
 --without-libotf --without-m17n-flt --with-x-toolkit=lucid
 --without-xaw3d GENTOO_PACKAGE=app-editors/emacs-vcs-24.3.9999
 EBZR_BRANCH=trunk EBZR_REVNO=111428'

Important settings:
  value of $LC_ALL: ru_RU.UTF-8
  value of $LANG: russian
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Message #8 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, 13374 <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Mon, 07 Jan 2013 20:05:06 -0500

Hi Ted,

Could you look at this report, with a view to possibly changing it in
emacs-24 branch, if appropriate? Thanks.

Oleksii Shevchuk wrote:

> open-gnutls-stream wrapper doesn't pass :verify-hostname-error t
> :verify-error t to gnutls-negotiate. So MitM is possible when you use
> gnus and other packages. 
>
> Even with :verify-hostname-error t :verify-error t gnutls-negotiate
> doesn't produce error with selfsigned CA certificate, when :type
> 'gnutls-x509pki passed.
>
> I use next in my .gnus:
>
> (defun open-gnutls-stream (name buffer host service)
>   (gnutls-negotiate :process (open-network-stream name buffer host service)
>                     :hostname host
>                     :verify-hostname-error t :verify-error t))
>

Message #11 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, 13374 <at> debbugs.gnu.org,
	Ted Zlatanov <tzz <at> lifelogs.com>
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 05:20:00 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> Could you look at this report, with a view to possibly changing it in
> emacs-24 branch, if appropriate? Thanks.

Well, the issue is what we do when we get a certificate we can't
validate.

The traditional thing to do is to query the user for whether to connect
anyway, and whether to record a permanent exception for that
certificate.

The code to do that hasn't been written yet.

It's very common for SMTP and IMAP servers to use self-signed
certificates, so just forcing ":validate t" for all connections would
essentially mean that Emacs would be unusable for reading/sending email
(using encryption) before that code has been written.

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

Message #14 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, 13374 <at> debbugs.gnu.org,
	Ted Zlatanov <tzz <at> lifelogs.com>
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Mon, 07 Jan 2013 23:27:23 -0500

Lars Magne Ingebrigtsen wrote:

> Well, the issue is what we do when we get a certificate we can't
> validate.
>
> The traditional thing to do is to query the user for whether to connect
> anyway, and whether to record a permanent exception for that
> certificate.
>
> The code to do that hasn't been written yet.
>
> It's very common for SMTP and IMAP servers to use self-signed
> certificates, so just forcing ":validate t" for all connections would
> essentially mean that Emacs would be unusable for reading/sending email
> (using encryption) before that code has been written.

Ah well, ok, thanks for the explanation. It sounds then like it's
probably better to leave this for trunk rather than try and force it
into 24.3 at this relatively late stage.

Message #17 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, 13374 <at> debbugs.gnu.org,
	Ted Zlatanov <tzz <at> lifelogs.com>
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 05:42:52 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> Ah well, ok, thanks for the explanation. It sounds then like it's
> probably better to leave this for trunk rather than try and force it
> into 24.3 at this relatively late stage.

Definitely.

Deciding on policies for handling opportunistic STARTTLS upgrades
combined with certificate failures has to be decided on, too.

That is, even if the user hasn't requested a TLS connection, Emacs will
auto-negotiate a STARTTLS connection now for virtually all protocol
types now.  If that "fails" because the certificate is self-signed or
expired, do we then want to bother the user by prompting for an action?
The user hasn't requested encryption and validation, but then this
question comes out of the blue?

So, er, someone (ahem) has to go through all the permutations of
connection types and failure modes, and write up some stuff.  We should
also have certificate management code in there somewhere so that the
user may be alerted if a privately signed certificate changes,
perhaps...

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

Message #20 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, Glenn Morris <rgm <at> gnu.org>,
	13374 <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 09:43:22 -0500

On Tue, 08 Jan 2013 05:42:52 +0100 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote: 

LMI> Glenn Morris <rgm <at> gnu.org> writes:
>> Ah well, ok, thanks for the explanation. It sounds then like it's
>> probably better to leave this for trunk rather than try and force it
>> into 24.3 at this relatively late stage.

LMI> Definitely.

LMI> Deciding on policies for handling opportunistic STARTTLS upgrades
LMI> combined with certificate failures has to be decided on, too.

LMI> That is, even if the user hasn't requested a TLS connection, Emacs will
LMI> auto-negotiate a STARTTLS connection now for virtually all protocol
LMI> types now.  If that "fails" because the certificate is self-signed or
LMI> expired, do we then want to bother the user by prompting for an action?
LMI> The user hasn't requested encryption and validation, but then this
LMI> question comes out of the blue?

LMI> So, er, someone (ahem) has to go through all the permutations of
LMI> connection types and failure modes, and write up some stuff.  We should
LMI> also have certificate management code in there somewhere so that the
LMI> user may be alerted if a privately signed certificate changes,
LMI> perhaps...

I propose to set up a verification list with the following format:

#+begin_src lisp
((".*\\.gmail.com" . (:verify-hostname-error t :verify-error t))
 (".*\\.yahoo.com" . t) ; everything
 (".*" . nil)) ; nothing
#+end_src

It should default to nil (in other words, we'll ship 24.3 with the same
insecure behavior it has right now).  But we can recommend to the users
to turn it on, and see how well it works in practice, and write the
necessary prompts and customization logic that Lars outlined.

I think that's OK for 24.3 since it's a completely unobtrusive change
that opens the road for improvements.

The main reason I didn't turn cert and hostname verification on sooner
is that I wasn't certain that our knowledge of platform CA store
filenames and general logic were good enough.  But it was always the
long-term plan, and I'm glad Oleksii brought it up.

Thanks
Ted

Message #23 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, 13374 <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 15:49:28 +0100

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> It should default to nil (in other words, we'll ship 24.3 with the same
> insecure behavior it has right now).  But we can recommend to the users
> to turn it on, and see how well it works in practice, and write the
> necessary prompts and customization logic that Lars outlined.

I think we should just leave things as is for 24.3, since it's too close
to release, and fix this properly for 24.5.  Instituting an option like
that (which will have to be abandoned later) as a stop-gap I feel isn't
all that helpful.

I think.

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

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 10:24:43 -0500

On Tue, 08 Jan 2013 15:49:28 +0100 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote: 

LMI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> It should default to nil (in other words, we'll ship 24.3 with the same
>> insecure behavior it has right now).  But we can recommend to the users
>> to turn it on, and see how well it works in practice, and write the
>> necessary prompts and customization logic that Lars outlined.

LMI> I think we should just leave things as is for 24.3, since it's too close
LMI> to release, and fix this properly for 24.5.  Instituting an option like
LMI> that (which will have to be abandoned later) as a stop-gap I feel isn't
LMI> all that helpful.

LMI> I think.

OK with me.  Is there a way to mark the bug is deferred so?  Maybe a fix-version?

Ted

Message #29 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>, Glenn Morris <rgm <at> gnu.org>,
	13374 <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Tue, 08 Jan 2013 12:06:08 -0500

>> It should default to nil (in other words, we'll ship 24.3 with the same
>> insecure behavior it has right now).  But we can recommend to the users
>> to turn it on, and see how well it works in practice, and write the
>> necessary prompts and customization logic that Lars outlined.
> I think we should just leave things as is for 24.3, since it's too close
> to release, and fix this properly for 24.5.

I tend to agree, although, if the patch is sufficiently trivial, it
could be accepted (e.g. define a new custom var, with nil default value
and splice it somewhere in the code where nil makes no difference).

> Instituting an option like that (which will have to be abandoned
> later) as a stop-gap I feel isn't all that helpful.

If the option will have to be abandoned, then it's indeed a loser, but
I thought the idea is that this option will stay and the added code in
24.4 will "simply" be handling errors more cleverly and prompting the
user to update this option on-the-fly.


        Stefan

Message #34 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13374 <at> debbugs.gnu.org, 13877 <at> debbugs.gnu.org,
	Moritz Ulrich <moritz <at> tarn-vedra.de>
Subject: Re: bug#13877: 24.3; gnutls.el: Enable Certificate Checks
Date: Thu, 14 Mar 2013 08:19:09 -0400

On Tue, 05 Mar 2013 11:51:33 -0500 Glenn Morris <rgm <at> gnu.org> wrote: 

GM> Moritz Ulrich wrote:
>> Currently, gnutls.el doesn't check certificate signatures when used via
>> `open-network-stream' with :type 'tls or `open-gnutls-stream'.

GM> Please see http://debbugs.gnu.org/13374
GM> It was considered too complicated to fix this properly for 24.3.

>> There is NO way to set :verify-host, :verify-flags, etc. for this call
>> to `gnutls-negotiate' when using gnutls via high-level functions like
>> `open-network-stream'.
>> 
>> I consider this a bug, as Emacs won't check any certificates and
>> therefore allow man in the middle attacks without even documenting this.
>> 
>> It should at least be possible to pass :verify-* from
>> `open-network-stream' down to `gnutls-negotiate'. That would be a simple
>> yet effective solution.

I would like to fix this properly now that 24.3 is out, but perhaps the
emacs-devel mailing list is a better place to work on it?

Ted

Message #37 received at 13374 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Glenn Morris <rgm <at> gnu.org>, Moritz Ulrich <moritz <at> tarn-vedra.de>
Cc: 13374 <at> debbugs.gnu.org, 13877 <at> debbugs.gnu.org
Subject: Re: bug#13374: bug#13877: 24.3; gnutls.el: Enable Certificate Checks
Date: Wed, 27 Mar 2013 09:20:46 -0400

On Thu, 14 Mar 2013 08:19:09 -0400 Ted Zlatanov <tzz <at> lifelogs.com> wrote: 

TZ> On Tue, 05 Mar 2013 11:51:33 -0500 Glenn Morris <rgm <at> gnu.org> wrote: 
GM> Moritz Ulrich wrote:
>>> Currently, gnutls.el doesn't check certificate signatures when used via
>>> `open-network-stream' with :type 'tls or `open-gnutls-stream'.

GM> Please see http://debbugs.gnu.org/13374
GM> It was considered too complicated to fix this properly for 24.3.

TZ> I would like to fix this properly now that 24.3 is out, but perhaps the
TZ> emacs-devel mailing list is a better place to work on it?

I started the discussion in emacs-devel.  Please contribute your ideas
and opinions.

Ted

Message #46 received at 13374-done <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>,
 Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 13374-done <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Wed, 18 Dec 2013 17:50:39 -0500

On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote: 

>>> It should default to nil (in other words, we'll ship 24.3 with the same
>>> insecure behavior it has right now).  But we can recommend to the users
>>> to turn it on, and see how well it works in practice, and write the
>>> necessary prompts and customization logic that Lars outlined.
>> I think we should just leave things as is for 24.3, since it's too close
>> to release, and fix this properly for 24.5.

SM> I tend to agree, although, if the patch is sufficiently trivial, it
SM> could be accepted (e.g. define a new custom var, with nil default value
SM> and splice it somewhere in the code where nil makes no difference).

>> Instituting an option like that (which will have to be abandoned
>> later) as a stop-gap I feel isn't all that helpful.

SM> If the option will have to be abandoned, then it's indeed a loser, but
SM> I thought the idea is that this option will stay and the added code in
SM> 24.4 will "simply" be handling errors more cleverly and prompting the
SM> user to update this option on-the-fly.

This is done for the upcoming release.  Marking this as done.

Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.