--- Begin Message ---
|
Subject: |
24.3; gnutls.el: Enable Certificate Checks |
|
Date: |
Tue, 05 Mar 2013 11:40:09 +0100 |
|
User-agent: |
mu4e 0.9.9; emacs 24.3.1 |
Currently, gnutls.el doesn't check certificate signatures when used via
`open-network-stream' with :type 'tls or `open-gnutls-stream'.
This is caused by the following code from `open-gnutls-stream'
(gnutls.el:110):
--8<---------------cut here---------------start------------->8---
(gnutls-negotiate :process (open-network-stream name buffer host service)
:type 'gnutls-x509pki
:hostname host)
--8<---------------cut here---------------end--------------->8---
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.
In GNU Emacs 24.3.1 (x86_64-apple-darwin11.4.2, NS apple-appkit-1138.51)
of 2013-03-05 on Moritzs-MacBook-Air
Windowing system distributor `Apple', version 10.3.1138
Configured using:
`configure '--prefix=/usr/local/Cellar/emacs/24.3-rc1' '--without-dbus'
'--enable-locallisppath=/usr/local/share/emacs/site-lisp'
'--infodir=/usr/local/Cellar/emacs/24.3-rc1/share/info/emacs'
'--with-ns' '--disable-ns-self-contained' '--with-gnutls' '--with-jpeg'
'--with-xml2' '--with-imagemagick' 'CC=cc''
<#secure method=pgpmime mode=sign>
--
Moritz Ulrich
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#13374: 24.?; open-gnutls-stream insecurity |
|
Date: |
Wed, 18 Dec 2013 17:50:39 -0500 |
|
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <address@hidden> 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
--- End Message ---