unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#13374: 24.?; open-gnutls-stream insecurity
@ 2013-01-07 10:20 Oleksii Shevchuk
  2013-01-08  1:05 ` Glenn Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Oleksii Shevchuk @ 2013-01-07 10:20 UTC (permalink / raw)
  To: 13374


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






^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-07 10:20 bug#13374: 24.?; open-gnutls-stream insecurity Oleksii Shevchuk
@ 2013-01-08  1:05 ` Glenn Morris
  2013-01-08  4:20   ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: Glenn Morris @ 2013-01-08  1:05 UTC (permalink / raw)
  To: Ted Zlatanov; +Cc: Oleksii Shevchuk, 13374


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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08  1:05 ` Glenn Morris
@ 2013-01-08  4:20   ` Lars Magne Ingebrigtsen
  2013-01-08  4:27     ` Glenn Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2013-01-08  4:20 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Oleksii Shevchuk, 13374, Ted Zlatanov

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/





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08  4:20   ` Lars Magne Ingebrigtsen
@ 2013-01-08  4:27     ` Glenn Morris
  2013-01-08  4:42       ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: Glenn Morris @ 2013-01-08  4:27 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: Oleksii Shevchuk, 13374, Ted Zlatanov

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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08  4:27     ` Glenn Morris
@ 2013-01-08  4:42       ` Lars Magne Ingebrigtsen
  2013-01-08 14:43         ` Ted Zlatanov
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2013-01-08  4:42 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Oleksii Shevchuk, 13374, Ted Zlatanov

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/





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08  4:42       ` Lars Magne Ingebrigtsen
@ 2013-01-08 14:43         ` Ted Zlatanov
  2013-01-08 14:49           ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: Ted Zlatanov @ 2013-01-08 14:43 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: Oleksii Shevchuk, 13374

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08 14:43         ` Ted Zlatanov
@ 2013-01-08 14:49           ` Lars Magne Ingebrigtsen
  2013-01-08 15:24             ` Ted Zlatanov
  2013-01-08 17:06             ` Stefan Monnier
  0 siblings, 2 replies; 10+ messages in thread
From: Lars Magne Ingebrigtsen @ 2013-01-08 14:49 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Oleksii Shevchuk, 13374

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/





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08 14:49           ` Lars Magne Ingebrigtsen
@ 2013-01-08 15:24             ` Ted Zlatanov
  2013-01-08 17:06             ` Stefan Monnier
  1 sibling, 0 replies; 10+ messages in thread
From: Ted Zlatanov @ 2013-01-08 15:24 UTC (permalink / raw)
  To: 13374

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






^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08 14:49           ` Lars Magne Ingebrigtsen
  2013-01-08 15:24             ` Ted Zlatanov
@ 2013-01-08 17:06             ` Stefan Monnier
  2013-12-18 22:50               ` Ted Zlatanov
  1 sibling, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2013-01-08 17:06 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: Oleksii Shevchuk, 13374

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#13374: 24.?; open-gnutls-stream insecurity
  2013-01-08 17:06             ` Stefan Monnier
@ 2013-12-18 22:50               ` Ted Zlatanov
  0 siblings, 0 replies; 10+ messages in thread
From: Ted Zlatanov @ 2013-12-18 22:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Oleksii Shevchuk, Lars Magne Ingebrigtsen, 13374-done

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-12-18 22:50 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-07 10:20 bug#13374: 24.?; open-gnutls-stream insecurity Oleksii Shevchuk
2013-01-08  1:05 ` Glenn Morris
2013-01-08  4:20   ` Lars Magne Ingebrigtsen
2013-01-08  4:27     ` Glenn Morris
2013-01-08  4:42       ` Lars Magne Ingebrigtsen
2013-01-08 14:43         ` Ted Zlatanov
2013-01-08 14:49           ` Lars Magne Ingebrigtsen
2013-01-08 15:24             ` Ted Zlatanov
2013-01-08 17:06             ` Stefan Monnier
2013-12-18 22:50               ` Ted Zlatanov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).