bug#13374: 24.?; open-gnutls-stream insecurity

bug#13374: 24.?; open-gnutls-stream insecurity

[Oleksii Shevchuk]

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

bug#13374: 24.?; open-gnutls-stream insecurity

[Glenn Morris]

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

bug#13374: 24.?; open-gnutls-stream insecurity

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@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/

bug#13374: 24.?; open-gnutls-stream insecurity

[Glenn Morris]

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.

bug#13374: 24.?; open-gnutls-stream insecurity

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@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/

bug#13374: 24.?; open-gnutls-stream insecurity

[Ted Zlatanov]

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

LMI> Glenn Morris <rgm@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

bug#13374: 24.?; open-gnutls-stream insecurity

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@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/

bug#13374: 24.?; open-gnutls-stream insecurity

[Ted Zlatanov]

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

LMI> Ted Zlatanov <tzz@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

bug#13374: 24.?; open-gnutls-stream insecurity

[Stefan Monnier]

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

bug#13374: 24.?; open-gnutls-stream insecurity

[Ted Zlatanov]

On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <monnier@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