Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Rob Browning]

[When possible, please preserve the -forwarded address in any replies.]

The following issue was just reported against emacs23 in Debian, and
from a quick glance, it looks like 24.4 still uses s_client, so if this
is a problem, it's perhaps still relevant.

Kurt Roeckx <kurt@roeckx.be> writes:

> It has come to my attention that Gnus is using s_client to set up
> SSL connections to retrieve email.  Please stop using that.
> s_client is a debug tool, it does not set up a secure connection,
> it ignores all errors and just continues.  It also doesn't do
> checks it should be doing.  This is all documented behaviour.
>
> Please get rid of all documentation, configurations and examples
> that tell you how to set it up using s_client.
>
> I've also seen examples adding -ssl2 and -ssl3 which is really
> really broken.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> The following issue was just reported against emacs23 in Debian, and
> from a quick glance, it looks like 24.4 still uses s_client, so if this
> is a problem, it's perhaps still relevant.

Oh, and the link (for the emacs24 bug cloned from the emacs23 bug) is
here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766397

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Wed, 22 Oct 2014 15:05:02 -0500 Rob Browning <rlb@defaultvalue.org> wrote: 

RB> Rob Browning <rlb@defaultvalue.org> writes:
>> The following issue was just reported against emacs23 in Debian, and
>> from a quick glance, it looks like 24.4 still uses s_client, so if this
>> is a problem, it's perhaps still relevant.

RB> Oh, and the link (for the emacs24 bug cloned from the emacs23 bug) is
RB> here:

RB>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766397

Hi Rob,

could you provide a test case?  The information gathered by
`M-x report-emacs-bug' would be really helpful, too.

Ted

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Rob Browning]

Ted Zlatanov <tzz@lifelogs.com> writes:

> could you provide a test case?  The information gathered by
> `M-x report-emacs-bug' would be really helpful, too.

Hmm, I'm not the original reporter, and don't yet deeply understand the
relevant issues, but on the surface, the "bug" appears to just ask that
Emacs "stop using or mentioning s_client".

If that turns out to be a reasonable request, then I'd imagine that the
code in imap.el, etc. would need adjustment, i.e.

  (defcustom imap-ssl-program '("openssl s_client -quiet -ssl3 -connect %s:%p"
                                "openssl s_client -quiet -ssl2 -connect %s:%p"
                                "s_client -quiet -ssl3 -connect %s:%p"
                                "s_client -quiet -ssl2 -connect %s:%p")

In any case, I can certainly send you the report-emacs-bug information
from my system, but the bug didn't originate there (I don't even have
emacs23 installed at the moment).  Did you mean for Kurt to send it?

And what kind of test did you have in mind?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Thu, 23 Oct 2014 10:57:17 -0500 Rob Browning <rlb@defaultvalue.org> wrote: 

RB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> could you provide a test case?  The information gathered by
>> `M-x report-emacs-bug' would be really helpful, too.

RB> Hmm, I'm not the original reporter, and don't yet deeply understand the
RB> relevant issues, but on the surface, the "bug" appears to just ask that
RB> Emacs "stop using or mentioning s_client".

I replied to the bug address as well, so I hope Kurt responds with a recipe.

RB> If that turns out to be a reasonable request, then I'd imagine that the
RB> code in imap.el, etc. would need adjustment, i.e.

No, the logic that needs to change is the one that opens the network
stream (and imap.el will be obsoleted, as Lars and Stefan mentioned).
But I'd like to know what's using imap.el in Kurt's case because I don't
know of any code that uses it.  Was he just warning that imap.el *could*
use s_client?  I went to the original bug report and couldn't find that
information, sorry.

RB> In any case, I can certainly send you the report-emacs-bug information
RB> from my system, but the bug didn't originate there (I don't even have
RB> emacs23 installed at the moment).  Did you mean for Kurt to send it?

Yes, sorry, the web interface misled me.  Kurt?

RB> And what kind of test did you have in mind?

Some code that lets me replicate the bug or issue on a Debian system,
with enough information to let me bring up such a system in a virtual
environment.

Ted

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Kurt Roeckx]

On Fri, Oct 24, 2014 at 09:39:28AM -0400, Ted Zlatanov wrote:
> On Thu, 23 Oct 2014 10:57:17 -0500 Rob Browning <rlb@defaultvalue.org> wrote: 
> 
> RB> Ted Zlatanov <tzz@lifelogs.com> writes:
> >> could you provide a test case?  The information gathered by
> >> `M-x report-emacs-bug' would be really helpful, too.
> 
> RB> Hmm, I'm not the original reporter, and don't yet deeply understand the
> RB> relevant issues, but on the surface, the "bug" appears to just ask that
> RB> Emacs "stop using or mentioning s_client".
> 
> I replied to the bug address as well, so I hope Kurt responds with a recipe.
> 
> RB> If that turns out to be a reasonable request, then I'd imagine that the
> RB> code in imap.el, etc. would need adjustment, i.e.
> 
> No, the logic that needs to change is the one that opens the network
> stream (and imap.el will be obsoleted, as Lars and Stefan mentioned).
> But I'd like to know what's using imap.el in Kurt's case because I don't
> know of any code that uses it.  Was he just warning that imap.el *could*
> use s_client?  I went to the original bug report and couldn't find that
> information, sorry.
> 
> RB> In any case, I can certainly send you the report-emacs-bug information
> RB> from my system, but the bug didn't originate there (I don't even have
> RB> emacs23 installed at the moment).  Did you mean for Kurt to send it?
> 
> Yes, sorry, the web interface misled me.  Kurt?
> 
> RB> And what kind of test did you have in mind?
> 
> Some code that lets me replicate the bug or issue on a Debian system,
> with enough information to let me bring up such a system in a virtual
> environment.

Someone suggested I should reply to this.

First, I'm not an emacs user, I'm the openssl maintainer in
Debian.  I think this started with me disabling SSLv3 support and
then getting reports that I broke emacs / gnus and I just looked
around what was going on.

From what I understand, it is (or was) possible to configure
things in such a way that it uses s_client to set up SSL, even
when it's configured to use gnutls.  You should never use s_client
for that.  s_client is a debug tool.  It does create an SSL
connection for you, but in an insecure way.

When looking around, I saw examples of using s_client in combination
with "-ssl2" and "-ssl3".  That is, only support those protocol
versions.  They are so broken that I removed support for them.
You should clearly never document that they should use those
options.  That probably all comes from the time SSLv2 and SSLv3
were the only 2 supported protocol versions, and you should
probably update the documentation to have more recent information
in it.

I hope this clears things up.


Kurt

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Ingebrigtsen]

Kurt Roeckx <kurt@roeckx.be> writes:

> From what I understand, it is (or was) possible to configure
> things in such a way that it uses s_client to set up SSL, even
> when it's configured to use gnutls.  You should never use s_client
> for that.  s_client is a debug tool.  It does create an SSL
> connection for you, but in an insecure way.

Emacs has built-in TLS support these days, so s_client is only used if
the user (for some weird reason or other) has built or installed a
version of Emacs without TLS support.

I think that should probably be removed, because it's less secure than
users would expect.

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

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Antoine Beaupre]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Sun, Feb 21, 2016 at 01:47:45PM +1100, Lars Ingebrigtsen wrote:
> Kurt Roeckx <kurt@roeckx.be> writes:
> 
> > From what I understand, it is (or was) possible to configure
> > things in such a way that it uses s_client to set up SSL, even
> > when it's configured to use gnutls.  You should never use s_client
> > for that.  s_client is a debug tool.  It does create an SSL
> > connection for you, but in an insecure way.
> 
> Emacs has built-in TLS support these days, so s_client is only used if
> the user (for some weird reason or other) has built or installed a
> version of Emacs without TLS support.
> 
> I think that should probably be removed, because it's less secure than
> users would expect.

This is now a release-blocking bug, but hasn't seen any activity in the
last year or so. It would be good to see this finally fixed!

Obviously, one should never use openssl s_client for stuff like this...
I should also note that even though Emacs 24 supports TLS natively now,
its handling of X509 certificate is really problematic, as documented in
#816063. I would hardly consider it complete.

Emacs 25 doesn't suffer from those issues, but may still allow
s_client...

A.

-- 
Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser,
nier ou simplement oublier l’adolescent que nous fûmes est en soi une
attitude adolescente.
                        - Daniel Pennac, Comme un roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Rob Browning]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Antoine Beaupre <anarcat@debian.org> writes:

> Obviously, one should never use openssl s_client for stuff like this...
> I should also note that even though Emacs 24 supports TLS natively now,
> its handling of X509 certificate is really problematic, as documented in
> #816063.

I've just uploaded emacs24 24.5+1-9 and requested an unblock to
hopefully address #816063 by configuring --without-gnutls, depending on
gnutls-cli, and backporting three upstream patches that remove the
--insecure argument from the gnutls-cli invocation and have it use
system certificates.

With respect to *this* bug, I'm slightly wary of the part of the patch
suggested earlier that removes imap-ssl-open entirely, since it seems
possible that external (user or other) code might be using it, perhaps
with full knowledge of its limitations.

So assuming (as suggested in the original patch) that it's
appropriate/acceptable to just substitute imap-tls-open for
imap-ssl-open, then I wondered if this or something like it might
address the immediate concerns:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: possible-s-client-fix.diff --]
[-- Type: text/x-diff, Size: 3297 bytes --]

From 9db659f9f18a79c7295e609472deb66467be0dbb Mon Sep 17 00:00:00 2001
From: Rob Browning <rlb@defaultvalue.org>
Date: Sun, 16 Apr 2017 12:08:07 -0500
Subject: Don't use s_client

---
 lisp/net/imap.el |  2 +-
 lisp/net/tls.el  | 15 +++++----------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/lisp/net/imap.el b/lisp/net/imap.el
index 3e59823..47f3d01 100644
--- a/lisp/net/imap.el
+++ b/lisp/net/imap.el
@@ -293,7 +293,7 @@ Shorter values mean quicker response, but is more CPU intensive."
   '((gssapi    imap-gssapi-stream-p    imap-gssapi-open)
     (kerberos4 imap-kerberos4-stream-p imap-kerberos4-open)
     (tls       imap-tls-p              imap-tls-open)
-    (ssl       imap-ssl-p              imap-ssl-open)
+    (ssl       imap-tls-p              imap-tls-open)
     (network   imap-network-p          imap-network-open)
     (shell     imap-shell-p            imap-shell-open)
     (starttls  imap-starttls-p         imap-starttls-open))
diff --git a/lisp/net/tls.el b/lisp/net/tls.el
index 68a3ff6..287de40 100644
--- a/lisp/net/tls.el
+++ b/lisp/net/tls.el
@@ -78,8 +78,7 @@ and `gnutls-cli' (version 2.0.1) output."
 
 (defcustom tls-program
   '("gnutls-cli --x509cafile %t -p %p %h"
-    "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3"
-    "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
+    "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3")
   "List of strings containing commands to start TLS stream to a host.
 Each entry in the list is tried until a connection is successful.
 %h is replaced with server hostname, %p with port to connect to.
@@ -93,20 +92,17 @@ successful negotiation."
   '(choice
     (const :tag "Default list of commands"
 	   ("gnutls-cli --x509cafile %t -p %p %h"
-	    "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3"
-	    "openssl s_client -CAfile %t -connect %h:%p -no_ssl2 -ign_eof"))
+	    "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3"))
     (list :tag "Choose commands"
 	  :value
 	  ("gnutls-cli --x509cafile %t -p %p %h"
-	   "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3"
-	   "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
+	   "gnutls-cli --x509cafile %t -p %p %h --protocols ssl3")
 	  (set :inline t
 	       ;; FIXME: add brief `:tag "..."' descriptions.
 	       ;; (repeat :inline t :tag "Other" (string))
 	       ;; No trust check:
 	       (const "gnutls-cli --insecure -p %p %h")
-	       (const "gnutls-cli --insecure -p %p %h --protocols ssl3")
-	       (const "openssl s_client -connect %h:%p -no_ssl2 -ign_eof"))
+	       (const "gnutls-cli --insecure -p %p %h --protocols ssl3"))
 	  (repeat :inline t :tag "Other" (string)))
     (list :tag "List of commands"
 	  (repeat :tag "Command" (string))))
@@ -137,8 +133,7 @@ consider trustworthy, e.g.:
 
 \(setq tls-program
       '(\"gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p %p %h\"
-	\"gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p %p %h --protocols ssl3\"
-	\"openssl s_client -connect %h:%p -CAfile /etc/ssl/certs/ca-certificates.crt -no_ssl2 -ign_eof\"))"
+	\"gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p %p %h --protocols ssl3\"))"
   :type '(choice (const :tag "Always" t)
 		 (const :tag "Never" nil)
 		 (const :tag "Ask" ask))
-- 
cgit v0.12


[-- Attachment #3: Type: text/plain, Size: 205 bytes --]


Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

> [When possible, please preserve the -forwarded address in any replies.]
> The following issue was just reported against emacs23 in Debian, and
> from a quick glance, it looks like 24.4 still uses s_client, so if this
> is a problem, it's perhaps still relevant.

AFAIK, nowadays Emacs only use s_client if it was not linked against
libgnutls (and it can use gnutls-cli instead as well, tho I don't know
which of s_client or gnutls-cli is given preference if both are found).


        Stefan

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Andreas Schwab]

Rob Browning <rlb@defaultvalue.org> writes:

> [When possible, please preserve the -forwarded address in any replies.]
>
> The following issue was just reported against emacs23 in Debian, and
> from a quick glance, it looks like 24.4 still uses s_client, so if this
> is a problem, it's perhaps still relevant.
>
> Kurt Roeckx <kurt@roeckx.be> writes:
>
>> It has come to my attention that Gnus is using s_client to set up
>> SSL connections to retrieve email.  Please stop using that.

That only happens if you use :stream ssl.  Use :stream tls or :stream
starttls instead.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Andreas Schwab]

This (untested) patch will make :stream ssl equivalent to :stream tls.

Andreas.

diff --git a/lisp/net/imap.el b/lisp/net/imap.el
index cf19e6c..9219b54 100644
--- a/lisp/net/imap.el
+++ b/lisp/net/imap.el
@@ -184,19 +184,6 @@ the list is tried until a successful connection is made."
   :group 'imap
   :type '(repeat string))
 
-(defcustom imap-ssl-program '("openssl s_client -quiet -ssl3 -connect %s:%p"
-			      "openssl s_client -quiet -ssl2 -connect %s:%p"
-			      "s_client -quiet -ssl3 -connect %s:%p"
-			      "s_client -quiet -ssl2 -connect %s:%p")
-  "A string, or list of strings, containing commands for SSL connections.
-Within a string, %s is replaced with the server address and %p with
-port number on server.  The program should accept IMAP commands on
-stdin and return responses to stdout.  Each entry in the list is tried
-until a successful connection is made."
-  :group 'imap
-  :type '(choice string
-		 (repeat string)))
-
 (defcustom imap-shell-program '("ssh %s imapd"
 				"rsh %s imapd"
 				"ssh %g ssh %s imapd"
@@ -286,14 +273,14 @@ Shorter values mean quicker response, but is more CPU intensive."
 (defvar imap-fetch-data-hook nil
   "Hooks called after receiving each FETCH response.")
 
-(defvar imap-streams '(gssapi kerberos4 starttls tls ssl network shell)
+(defvar imap-streams '(gssapi kerberos4 starttls tls network shell)
   "Priority of streams to consider when opening connection to server.")
 
 (defvar imap-stream-alist
   '((gssapi    imap-gssapi-stream-p    imap-gssapi-open)
     (kerberos4 imap-kerberos4-stream-p imap-kerberos4-open)
     (tls       imap-tls-p              imap-tls-open)
-    (ssl       imap-ssl-p              imap-ssl-open)
+    (ssl       imap-tls-p              imap-tls-open)
     (network   imap-network-p          imap-network-open)
     (shell     imap-shell-p            imap-shell-open)
     (starttls  imap-starttls-p         imap-starttls-open))
@@ -343,7 +330,6 @@ basis.")
 ;; Internal constants.  Change these and die.
 
 (defconst imap-default-port 143)
-(defconst imap-default-ssl-port 993)
 (defconst imap-default-tls-port 993)
 (defconst imap-default-stream 'network)
 (defconst imap-coding-system-for-read 'binary)
@@ -661,56 +647,6 @@ sure of changing the value of `foo'."
 	      nil)))))
     done))
 
-(defun imap-ssl-p (_buffer)
-  nil)
-
-(defun imap-ssl-open (name buffer server port)
-  "Open an SSL connection to SERVER."
-  (let ((cmds (if (listp imap-ssl-program) imap-ssl-program
-		(list imap-ssl-program)))
-	cmd done)
-    (while (and (not done) (setq cmd (pop cmds)))
-      (message "imap: Opening SSL connection with `%s'..." cmd)
-      (erase-buffer)
-      (let* ((port (or port imap-default-ssl-port))
-	     (coding-system-for-read imap-coding-system-for-read)
-	     (coding-system-for-write imap-coding-system-for-write)
-	     (process-connection-type imap-process-connection-type)
-	     (set-process-query-on-exit-flag
-	      (if (fboundp 'set-process-query-on-exit-flag)
-		  'set-process-query-on-exit-flag
-		'process-kill-without-query))
-	     process)
-	(when (progn
-		(setq process (start-process
-			       name buffer shell-file-name
-			       shell-command-switch
-			       (format-spec cmd
-					    (format-spec-make
-					     ?s server
-					     ?p (number-to-string port)))))
-		(funcall set-process-query-on-exit-flag process nil)
-		process)
-	  (with-current-buffer buffer
-	    (goto-char (point-min))
-	    (while (and (memq (process-status process) '(open run))
-			(set-buffer buffer) ;; XXX "blue moon" nntp.el bug
-			(goto-char (point-max))
-			(forward-line -1)
-			(not (imap-parse-greeting)))
-	      (accept-process-output process 1)
-	      (sit-for 1))
-	    (imap-log buffer)
-	    (erase-buffer)
-	    (when (memq (process-status process) '(open run))
-	      (setq done process))))))
-    (if done
-	(progn
-	  (message "imap: Opening SSL connection with `%s'...done" cmd)
-	  done)
-      (message "imap: Opening SSL connection with `%s'...failed" cmd)
-      nil)))
-
 (defun imap-tls-p (_buffer)
   nil)
 
@@ -2965,8 +2901,6 @@ Return nil if no complete line has arrived."
 	  imap-error-text
 	  imap-kerberos4s-p
 	  imap-kerberos4-open
-	  imap-ssl-p
-	  imap-ssl-open
 	  imap-network-p
 	  imap-network-open
 	  imap-interactive-login
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> This (untested) patch will make :stream ssl equivalent to :stream tls.

[...]

> diff --git a/lisp/net/imap.el b/lisp/net/imap.el
> index cf19e6c..9219b54 100644
> --- a/lisp/net/imap.el
> +++ b/lisp/net/imap.el

Is there anything that uses imap.el?  I thought it was obsolete...

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

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

> Is there anything that uses imap.el?  I thought it was obsolete...

Should we move it to lisp/obsolete, then?


        Stefan

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Is there anything that uses imap.el?  I thought it was obsolete...
>
> Should we move it to lisp/obsolete, then?

I grepped through the Emacs tree, and there seems to still be one
in-tree usage -- mail-source.el.  It uses imap.el to allow a simple
"download-from-IMAP" thing.  Which probably nobody uses, but should
still be present, I think.

So either mail-source.el should be rewritten to use something else (and
imap.el be obsoleted), or imap.el should be rewritten to use
`open-network-stream' instead of futzing around with TLS primitives
directly.

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

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Filipp Gunbin]

On 24/10/2014 11:01 +0400, Lars Magne Ingebrigtsen wrote:

> I grepped through the Emacs tree, and there seems to still be one
> in-tree usage -- mail-source.el.  It uses imap.el to allow a simple
> "download-from-IMAP" thing.  Which probably nobody uses, but should
> still be present, I think.

If I understood right, you're talking about using 'imap element in
mail-sources var - in that case I'm using it and find it very
convenient.

> So either mail-source.el should be rewritten to use something else (and
> imap.el be obsoleted), or imap.el should be rewritten to use
> `open-network-stream' instead of futzing around with TLS primitives
> directly.

-- 
    Filipp

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I've read that falling back to ssl3 is a real security hole,
being exploited frequently.  That feature should be removed.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Richard Stallman:

> I've read that falling back to ssl3 is a real security hole,
> being exploited frequently.  That feature should be removed.

GNUTLS automatically and securely upgrades to a TLS protocol if
supported by the server.  Dropping SSL 3.0 support altogether will
only encourage unencrypted connections instead.  Furthermore, SSL 3.0
is certainly not an ideal design, but neither is TLS 1.0.  Only
TLS 1.1 and later attempt to fix the padding issue, and support for
those versions is still poor in servers.  Fortunately, the padding
issues are only exploitable under fairly narrow circumstances.
Most applications (except web browsers) use SSL 3.0 in such a way that
the attack described in the POODLE paper does not apply.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Thu, 23 Oct 2014 20:00:08 +0200 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Richard Stallman:
> 
> > I've read that falling back to ssl3 is a real security hole,
> > being exploited frequently.  That feature should be removed.
> 
> GNUTLS automatically and securely upgrades to a TLS protocol if
> supported by the server.  Dropping SSL 3.0 support altogether will
> only encourage unencrypted connections instead.

I disagree. It will encourage people to upgrade from a flawed
protocol to one that works. Many people running servers are utterly
unaware that there's anything wrong with what they're using right now
-- if you leave in support forever, they'll never figure it out.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Perry E. Metzger:

> On Thu, 23 Oct 2014 20:00:08 +0200 Florian Weimer <fw@deneb.enyo.de>
> wrote:
>> * Richard Stallman:
>> 
>> > I've read that falling back to ssl3 is a real security hole,
>> > being exploited frequently.  That feature should be removed.
>> 
>> GNUTLS automatically and securely upgrades to a TLS protocol if
>> supported by the server.  Dropping SSL 3.0 support altogether will
>> only encourage unencrypted connections instead.
>
> I disagree. It will encourage people to upgrade from a flawed
> protocol to one that works. Many people running servers are utterly
> unaware that there's anything wrong with what they're using right now
> -- if you leave in support forever, they'll never figure it out.

Well, print a warning and sit for five seconds if you care so much
about that, but denying users access to their mail just because you
decided that SSL 3.0 is not secure enough anymore doesn't make much
sense.  Rallying against RC4 would be a better use of our time, I
suspect.

Keep in mind that TLS 1.0 basically has the same problem as SSL 3.0,
and support for protocols beyond TLS 1.0 is not actually widespread.

And to reiterate, if something better is available, the presence of
SSL 3.0 support on both ends does no harm (only with browsers, but
that's a browser bug).  TLS cryptographically protects against
downgrades.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Thu, 23 Oct 2014 20:43:32 +0200 Florian Weimer <fw@deneb.enyo.de>
> Keep in mind that TLS 1.0 basically has the same problem as SSL 3.0,
> and support for protocols beyond TLS 1.0 is not actually widespread.

Connections to most of the top sites are TLS 1.2 at this point.
Google is TLS 1.2. Facebook is TLS 1.2. Amazon is TLS 1.2. Apple is
TLS 1.2. I could go on and on.

All are using AES at this point and not RC4 as well.

I think you're a year behind on your claim.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Perry E. Metzger:

> On Thu, 23 Oct 2014 20:43:32 +0200 Florian Weimer <fw@deneb.enyo.de>
>> Keep in mind that TLS 1.0 basically has the same problem as SSL 3.0,
>> and support for protocols beyond TLS 1.0 is not actually widespread.
>
> Connections to most of the top sites are TLS 1.2 at this point.
> Google is TLS 1.2. Facebook is TLS 1.2. Amazon is TLS 1.2. Apple is
> TLS 1.2. I could go on and on.

Many IMAP servers running on free software still use OpenSSL 1.0.0 or
even OpenSSL 0.9.8, which do not support TLS 1.2.  Interoperability
with those should be our priority, not the proprietary services you
listed.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Kurt Roeckx]

On Thu, Oct 23, 2014 at 08:59:56PM +0200, Florian Weimer wrote:
> * Perry E. Metzger:
> 
> > On Thu, 23 Oct 2014 20:43:32 +0200 Florian Weimer <fw@deneb.enyo.de>
> >> Keep in mind that TLS 1.0 basically has the same problem as SSL 3.0,
> >> and support for protocols beyond TLS 1.0 is not actually widespread.
> >
> > Connections to most of the top sites are TLS 1.2 at this point.
> > Google is TLS 1.2. Facebook is TLS 1.2. Amazon is TLS 1.2. Apple is
> > TLS 1.2. I could go on and on.
> 
> Many IMAP servers running on free software still use OpenSSL 1.0.0 or
> even OpenSSL 0.9.8, which do not support TLS 1.2.  Interoperability
> with those should be our priority, not the proprietary services you
> listed.

TLS 1.1 and 1.2 support was added in OpenSSL 1.0.1.  It was
released in March 2012.  It's unfortunate that support wasn't
added much sooner.  But 1.0.X should be binary compatible with
1.0.0, and we recommend that you upgraded to either 1.0.1 or the
soon to be released 1.0.2.


Kurt

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Thu, 23 Oct 2014 20:59:56 +0200 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Perry E. Metzger:
> 
> > On Thu, 23 Oct 2014 20:43:32 +0200 Florian Weimer
> > <fw@deneb.enyo.de>
> >> Keep in mind that TLS 1.0 basically has the same problem as SSL
> >> 3.0, and support for protocols beyond TLS 1.0 is not actually
> >> widespread.
> >
> > Connections to most of the top sites are TLS 1.2 at this point.
> > Google is TLS 1.2. Facebook is TLS 1.2. Amazon is TLS 1.2. Apple
> > is TLS 1.2. I could go on and on.
> 
> Many IMAP servers running on free software still use OpenSSL 1.0.0
> or even OpenSSL 0.9.8, which do not support TLS 1.2.
> Interoperability with those should be our priority, not the
> proprietary services you listed.

Free software has supported TLS 1.2 for a long time. What you're
claiming is that you know of loads of people who have failed to
upgrade their software -- but it is of course easy to upgrade if
you run free software, because nothing prevents you from getting
updated packages. Yes, the OLD versions of the packages don't support
TLS 1.2, but the new packages are readily available.

Anyway, this attitude is why the NSA has such an easy time spying on
the world. "We can't afford to have security, people might get
inconvenienced for the length of time needed to upgrade their
systems."

The intelligence agencies thank you for your inadvertent assistance
in assuring that various kinds of downgrade, padding and other attacks
will remain feasible for years to come.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Perry E. Metzger:

> The intelligence agencies thank you for your inadvertent assistance
> in assuring that various kinds of downgrade, padding and other attacks
> will remain feasible for years to come.

Giving incorrect advice, like you do, does not make the Internet a
safer place, either.

I don't think it makes sense to continue the discussion.  Again, if
you are looking for something useful to do, rally against RC4, not SSL
3.0.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Thu, 23 Oct 2014 21:50:07 +0200 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Perry E. Metzger:
> 
> > The intelligence agencies thank you for your inadvertent
> > assistance in assuring that various kinds of downgrade, padding
> > and other attacks will remain feasible for years to come.
> 
> Giving incorrect advice, like you do, does not make the Internet a
> safer place, either.

You think telling people they should be using a secure protocol is
"incorrect advice"? Really? You think telling people to keep
providing vulnerable protocols by default is "correct" advice?

You couldn't be suggesting a policy more useful to the National
Security Agency -- this is exactly what they would prefer vendors
do, keep supporting insecure protocols forever, especially ones you
can force people into with downgrade attacks.

The real problem is that many users don't understand the tradeoffs or
that there's even an issue. If the software vendors (and FSF is a
software vendor) keep supporting old protocols forever, they never
*will* figure out they need to upgrade.

To reiterate: all the major sites already use TLS 1.2 with AES. All
open source TLS implementations implement 1.2 and AES. Ceasing to use
SSL 3.0 is simple (even ceasing to use TLS 1.0 and 1.1 is simple but
we're talking about SSL 3.0 here). So, why do we need to support SSL
3.0 again? What's the rationale, other than making the lives of
attackers easy?

> I don't think it makes sense to continue the discussion.  Again, if
> you are looking for something useful to do, rally against RC4, not
> SSL 3.0.

None of the big sites are using RC4 any more, and the open source TLS
implementations supply better algorithms, so what is there to rally
against? Now we have to rally against SHA-1 in certs vs. the use of
newer hash functions -- the world has moved on.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Kurt Roeckx]

On Thu, Oct 23, 2014 at 04:26:16PM -0400, Perry E. Metzger wrote:
> To reiterate: all the major sites already use TLS 1.2 with AES.

We don't only care about "major sites", there are plenty of
other sites.  But if you count youtube as a major site it will
talk RC4 to Firefox.  Bug agl announced that that is about to
change soon.

But you really should look at the stats of the "top 1 million"
sites I posted earlier if you want to know the state of the "major
sites".

> Ceasing to use
> SSL 3.0 is simple (even ceasing to use TLS 1.0 and 1.1 is simple but
> we're talking about SSL 3.0 here).

Ceasing to use TLS 1.0 is not simple.  Only about 50% of the
servers support higher version.  So we still need to support
TLS 1.0.  As Florian stated openssl 0.9.8 does not support TLS
1.1 or newer and 0.9.8 is still used way too much.

> So, why do we need to support SSL
> 3.0 again? What's the rationale, other than making the lives of
> attackers easy?

I'm all for dropping SSL 3.0 support and I disabled it in openssl
in Debian testing and unstable.  This was already planned for some
time, and the POODLE attack made me just do it.

But if your concern is about the POODLE attack, please note that
the attack requires many connection attemps where the attacker has
control over the plaintext that is being send.  This is relativly
easy to exploit in a browser but I don't know of any attack where
this can be done outside a browser.  So you want to do 1 or more
of the following:
- Disable SSLv3 in your browser
- Disable SSLv3 in your webserver
- Disable javascript

When talking about HTTPS there are clients and servers that
support SSL 3.0 but don't support TLS 1.0.  But the stats say it's
less than 1% for both of them.  Some people will care about that
1%, others won't.


Kurt

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Thu, 23 Oct 2014 23:05:46 +0200 Kurt Roeckx <kurt@roeckx.be> wrote:
> > So, why do we need to support SSL
> > 3.0 again? What's the rationale, other than making the lives of
> > attackers easy?
> 
> I'm all for dropping SSL 3.0 support and I disabled it in openssl
> in Debian testing and unstable.  This was already planned for some
> time, and the POODLE attack made me just do it.

Then we're pretty much in agreement already and no more needs to be
said. :)

> But if your concern is about the POODLE attack, please note that
> the attack requires many connection attemps where the attacker has
> control over the plaintext that is being send.

Long experience says that attacks only get stronger with time. (They
don't get weaker -- people don't forget attacks -- and smart people
often figure out refinements.) I prefer closing the door rather than
waiting to find out what the next implication of downgrade attacks is.

Anyway, you agree with me on the SSL 3.0 part, and I'm not seriously
suggesting TLS 1.0 be dropped *yet*, so we agree.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > Free software has supported TLS 1.2 for a long time. What you're
 > claiming is that you know of loads of people who have failed to
 > upgrade their software -- but it is of course easy to upgrade if
 > you run free software, because nothing prevents you from getting
 > updated packages.

Wrong.  Many people these days are using free software in corporate
environments where they need to get the new versions vetted by
corporate security.

You may not consider that a problem, but the people running those
sites do.

 > Anyway, this attitude is why the NSA has such an easy time spying on
 > the world. "We can't afford to have security, people might get
 > inconvenienced for the length of time needed to upgrade their
 > systems."

True.  So what?  It's a real effect, and your sneers aren't going to
affect their behavior.

Some problems are sufficiently severe that it's worth fixing them even
if it causes great inconvenience.  This one (as I understand it from
posts here) is not.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Fri, 24 Oct 2014 06:48:34 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> Perry E. Metzger writes:
> 
>  > Free software has supported TLS 1.2 for a long time. What you're
>  > claiming is that you know of loads of people who have failed to
>  > upgrade their software -- but it is of course easy to upgrade if
>  > you run free software, because nothing prevents you from getting
>  > updated packages.
> 
> Wrong.  Many people these days are using free software in corporate
> environments where they need to get the new versions vetted by
> corporate security.

I've been doing security in such environments for about the past 20
years. I'm plenty familiar with them. The sensitive users,
like banks, upgrade quite quickly.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > > Wrong.  Many people these days are using free software in corporate
 > > environments where they need to get the new versions vetted by
 > > corporate security.
 > 
 > I've been doing security in such environments for about the past 20
 > years. I'm plenty familiar with them. The sensitive users,
 > like banks, upgrade quite quickly.

But you're defining "sensitive" in terms of security, and that's the
wrong definition -- those sensitive users are already doing what you
advocate and don't need encouragement to upgrade their servers and so
on.[1]  It's security-insensitive users who would be inconvenienced,
and either turn to an alternative which still supports the vulnerable
protocol or turn off security entirely.  Sad to say, not all companies
with strict policies about what *you* can install are quick to upgrade
what *they* have installed.

Footnotes: 
[1]  It's true that these users *need* the option to turn off the less
secure protocol so it doesn't get used inadvertantly, and it's
probably desirable that it be off by default.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Sat, 25 Oct 2014 05:51:36 +0900 "Stephen J. Turnbull"
<turnbull@sk.tsukuba.ac.jp> wrote:
> But you're defining "sensitive" in terms of security, and that's the
> wrong definition -- those sensitive users are already doing what you
> advocate and don't need encouragement to upgrade their servers and
> so on.[1]  It's security-insensitive users who would be
> inconvenienced,

For a long time, the community believed that the relevant fact was
that most users were not security sensitive. Then we came to
understand that the same application software is used by your
grandfather and by reporters talking to sources about intelligence
agencies with hostile intent. It is also the case that few users with
high level security needs actually understand how to tune their
applications.

Unfortunately, the proper strategy is to code to the *highest* level
of security that a user of your application might need, not to the
average level of security one of your users might need.

Or, to quote the usual slogan, "there should only be one mode, and it
should be secure".

> [1]  It's true that these users *need* the option to turn off the
> less secure protocol so it doesn't get used inadvertantly, and it's
> probably desirable that it be off by default.

Turning off insecure modes of operation by default is a sort of
minimum, yes. However, it is usually insufficient if it is relatively
easy to turn security off and produces no feedback to the effect
that you are operating in insecure mode.

Once you've listened to the secret service or DEA chatting on the
radio in the clear by accident because they don't realize they
inadvertently turned off the encryption on their P25 radios (which is
trivial to do by accident and provides no warning feedback) you
realize that essentially *no* user can be trusted with such decisions
in the average case.

(This is not a theoretical story, by the way. And yes, you can read
our research group's papers about public safety radio security.)

When you study the failures in enough real world deployed systems,
even when used by trained personnel, you lose your belief that it
is okay to provide knobs to the users that they don't understand very
well. Really the only safe system follows "there should be only one
mode, and it should be secure".

Oh, and the reason P25 radios can be turned to the clear is... wait
for it... *for fallback compatibility*. People's lives have been
endangered by that little decision. (The only agency we found that
does not have serious leakage was the one that made the decision to
remove the clear option from their radios entirely. Somehow, they
found that they could live without compatibility with equipment
that could only do clear.)

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Magne Ingebrigtsen]

"Perry E. Metzger" <perry@piermont.com> writes:

> Once you've listened to the secret service or DEA chatting on the
> radio in the clear by accident because they don't realize they
> inadvertently turned off the encryption on their P25 radios (which is
> trivial to do by accident and provides no warning feedback) you
> realize that essentially *no* user can be trusted with such decisions
> in the average case.

[...]

> Really the only safe system follows "there should be only one
> mode, and it should be secure".

This is alarmist nonsense.

It's telling that your example is a case where, perhaps, it might have
made a difference whether the communication was secure or not.

However, the common case for a normal user is when you're binging around
for a solution as to why your Foobarzot device is not responding when
you're fsck-ing it, and the only place you can find discussion on this
topic is on a mailing list archive that has an expired certificate.

Do you still want to read that mailing list archive?  Yes.  You do.  

In real life, virtually all situations where the security of the
communication channel can't be verified, you simply don't care at all.
When you care, you usually know, because you work for the DEA or you're
trying to pay a bill via your bank.

The super-alarmist "don't allow the user to do what she obviously wants
to do" just makes the user to disable all security.

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

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Fri, 24 Oct 2014 23:33:01 +0200 Lars Magne Ingebrigtsen
<larsi@gnus.org> wrote:
> "Perry E. Metzger" <perry@piermont.com> writes:
> 
> > Once you've listened to the secret service or DEA chatting on the
> > radio in the clear by accident because they don't realize they
> > inadvertently turned off the encryption on their P25 radios
> > (which is trivial to do by accident and provides no warning
> > feedback) you realize that essentially *no* user can be trusted
> > with such decisions in the average case.
> 
> [...]
> 
> > Really the only safe system follows "there should be only one
> > mode, and it should be secure".
> 
> This is alarmist nonsense.

No, it is the result of working in security for about twenty years.

> It's telling that your example is a case where, perhaps, it might
> have made a difference whether the communication was secure or not.

As I've said earlier: the problem is that ordinary users use the same
applications as extraordinary ones. P25 radios are used both by
shopping mall security guards and by the US Secret Service. If you say
"oh, the security doesn't have to be perfect for a security guard",
you end up endangering the highest risk users.

When the reporters who dealt with Edward Snowden were communicating
with them, they didn't have the special unusual operating system
issued only to special reporters, they had the normal one. People
with secrets to keep use the same mail programs other people do, the
same text editors, the same web browsers.

You can't say "oh, most users don't need protection", or "well, for
most web sites the user doesn't need protection". You have to aim your
protection to the users you have with the highest need for secrecy,
your web browser for the banking application, not the times when the
user is browsing auto reviews.

> However, the common case for a normal user is when you're binging
> around for a solution as to why your Foobarzot device is not

And who cares, because that same user will also look at his bank
statements, and who cares, because the reporter who is talking to
someone risking their life in Iran just by communicating with a
Western journalist is using the same email program or web browser as
everyone else.

And let me be blunt: I'm sick of cleaning up the messes
software developers playing amateur security people have created for
the world over the last few decades. I spend my life cleaning up
messes caused by people who think they're smarter. SSL itself is an
example of this -- designed by people at Netscape who knew better and
didn't consult anyone who actually had any experience.

You read the full disclosure mailing list or the equivalent and you
see exactly what the amateurs have produced with their "oh, who would
think to do that" or "well, we need to be compatible" or their "well,
most users don't need protection" attitude, and worse, you see it day
after day, week after week.

You started this by saying that I was producing "alarmist nonsense".
Sadly, we live in a world where the largest banks in the world, the
largest retailers, etc. get broken in to regularly, where there are
spy agencies trying to record your, yes your, phone calls, never mind
how unimportant you think you are, where there are activists in
countries all of the world whose lives are put at risk by crappy
software, where most system security is a broken mess.

Quit playing amateur security expert. You're part of the problem when
you do.

> In real life, virtually all situations where the security of the
> communication channel can't be verified, you simply don't care at
> all.

Yes, but your software will not be used exclusively by people who
don't care, and you have no control over who uses your software.

> The super-alarmist "don't allow the user to do what she obviously
> wants to do" just makes the user to disable all security.

Not if you remove the ability to disable security. In fact, if you
let the user disable security, they'll be tricked into doing so by
social engineering attacks of various kinds, so you can't actually
leave that knob available anyway. That's not theoretical either. It
was a huge mistake that many of our protocols make security optional
-- a mistake being corrected in the new HTTP, by the way, which will
not even permit unencrypted connections.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Fri, 24 Oct 2014 23:33:01 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> The super-alarmist "don't allow the user to do what she obviously wants
LMI> to do" just makes the user to disable all security.

Yes, I'm very concerned that we will turn on GnuTLS verification and
make the priority string more strict, and users will conclude Emacs is
broken.  Then we'll see the advice "oh just go back to s_client and
you'll be fine."

I really need to know if GnuTLS can interact with Emacs Lisp during the
negotiation phases through C callbacks, because if it can, we'll be able
to catch and remedy these situations.  We discussed that earlier when
Toke submitted the TOFU patch and I'd appreciate some help.

Thanks
Ted

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I really need to know if GnuTLS can interact with Emacs Lisp during the
> negotiation phases through C callbacks, because if it can, we'll be able
> to catch and remedy these situations.  We discussed that earlier when
> Toke submitted the TOFU patch and I'd appreciate some help.

The proposed security manager would store certificate fingerprints, so
detecting when a known server drops from TLS 1.2 to SSL 3.0 would
presumably also be something we could warn about, just like we would
warn when we drop from STARTTLS to unencrypted.

"You are talking to imap:dea.gov via SSL 3.0 now, while last time you
did this via TLS 1.2.  This might mean that you're suffering from a
Man-In-The-Middle attack.  Still connect?"

I'm not actually sure we need a callback to handle this stuff.  I've
just looked very briefly at the libgnutls interface, and it kinda seems
to me like we could just do the connection, and then decide whether
we're satisfied with its properties (SSL 3.0, changed certificate,
privately signed certificate, etc) on the Emacs side.

But I'm quite likely misunderstanding something about how libgnutls
negotiates the connection.

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

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Lars Magne Ingebrigtsen:

> The proposed security manager would store certificate fingerprints, so
> detecting when a known server drops from TLS 1.2 to SSL 3.0 would
> presumably also be something we could warn about, just like we would
> warn when we drop from STARTTLS to unencrypted.
>
> "You are talking to imap:dea.gov via SSL 3.0 now, while last time you
> did this via TLS 1.2.  This might mean that you're suffering from a
> Man-In-The-Middle attack.  Still connect?"

Uhm, if this happens, the server has been downgraded.  The handshake
will fail if a man-in-the-middle attempts to force the use of SSL 3.0,
and both ends support something newer.  (As far as I can tell, Emacs
does not implement the vulnerable protocol downgrade code, unlike
browsers.)

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Lars Magne Ingebrigtsen]

Florian Weimer <fw@deneb.enyo.de> writes:

> Uhm, if this happens, the server has been downgraded.  The handshake
> will fail if a man-in-the-middle attempts to force the use of SSL 3.0,
> and both ends support something newer.  (As far as I can tell, Emacs
> does not implement the vulnerable protocol downgrade code, unlike
> browsers.)

Oh.  Than what's all this fuss about, then?  Just the normal churn of
"security professional" drama?

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

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Lars Magne Ingebrigtsen:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> Uhm, if this happens, the server has been downgraded.  The handshake
>> will fail if a man-in-the-middle attempts to force the use of SSL 3.0,
>> and both ends support something newer.  (As far as I can tell, Emacs
>> does not implement the vulnerable protocol downgrade code, unlike
>> browsers.)
>
> Oh.  Than what's all this fuss about, then?  Just the normal churn of
> "security professional" drama?

It's unusual in the sense that the actual vulnerability in SSL 3.0 was
fixed by subsequent protocol versions, beginning in 1999, and
surprisingly few were eager to point this out.  (It doesn't help that
for non-technical reasons, what should have been SSL 3.1 is now called
TLS 1.0.)

I have no good explanation why browser vendors are so wedded to their
broken fallback behavior.  Even if you assume that they are balancing
the their users' security needs and those of law enforcement agencies,
some communications still do not make sense.

Unfortunately, the early industry consensus (defined by those who were
in the original pre-disclosure circle) appears to have been to claim
that this fallback behavior is desirable, although it was never
standardized by the IETF, and not implemented in most (any?)
cryptographic libraries.  But that secret circle failed to do their
job properly, and their favorite remedy (TLS_FALLBACK_SCSV) is not
available in most released TLS implementations and major TLS-using
applications.  As a result, a “critical SSL vulnerability” hit the
news, and security-conscientious operators had literally no option at
hand to protect their user base, as it existed at that time (and not
much has changed in the few weeks since then).

Rather than admit to this failure and re-evaluate the browser fallback
behavior (or the claimed impact of the well-known SSL 3.0
vulnerabilities), the message turned into “disable SSL 3.0”, which is
something that is doable today with some effort.  (Some people even
prefer cleartext over SSL 3.0 encryption, which is rather bizarre, but
an understandable result of the situation.)  But considering that the
cryptographic libraries automatically upgrade away from SSL 3.0—if you
(as an application programmer) let them do their job, this step is
rather pointless busywork.  This effort only detracts from more
important work, such as enabling encryption (with proper
authentication, preferably) for additional services.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Yes, I'm very concerned that we will turn on GnuTLS verification and
    make the priority string more strict, and users will conclude Emacs is
    broken.  Then we'll see the advice "oh just go back to s_client and
    you'll be fine."

This could happen if users don't understand the issue.

Is it feasible to warn users about this
whenever it is about to fall back to SSL3 in cases where that would
cause a danger?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Richard Stallman:

> Is it feasible to warn users about this
> whenever it is about to fall back to SSL3 in cases where that would
> cause a danger?

No, because Emacs does not perform fallback.  (GNUTLS automatically
upgrades away from SSL 3.0 if possible, and this upgrade is a
cryptographically protected part of the handshake.)  Emacs could warn
if a connection uses SSL 3.0.  However, it will be difficult to
explain the exact implication of the warning.  At present, there is
not even consensus among programmers how bad SSL 3.0 actually is.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > When you study the failures in enough real world deployed systems,
 > even when used by trained personnel, you lose your belief that it
 > is okay to provide knobs to the users that they don't understand very
 > well. Really the only safe system follows "there should be only one
 > mode, and it should be secure".

I heard you the first time.  What your discussion ignores is that
that's already a moot point, especially in free software.  The
insecure alternative exists, is installed, and will be used in
preference to an upgrade with "one mode and that mode is secure" if
the inconvenience of security is great enough.

It's possible that the inconvenience is small.  Your anecdote about
P25 radios suggests that in that case in fact it was, but that can
only be determined by finding out whether organizations different in
many ways are the same in that dimension.  On the other hand, it is a
fact that people have died (and to this day are dying in Japan)
because of lack of compatibility between communication systems among
cooperating organizations such as fire and police.  It's possible that
fallback-to-compatible capability did matter and still does matter.

I'm not going to attempt to deny the importance of security, the lack
of information and training in use of optional security features among
users, or the rapid escalation of frequency and power of attacks.
Nevertheless, advocating extreme security policy is unlikely to
achieve the goal of extreme security in the current environment, and I
believe that a more balanced approach can do better.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Sat, 25 Oct 2014 06:47:37 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> It's possible that the inconvenience is small.  Your anecdote about
> P25 radios suggests that in that case in fact it was, but that can
> only be determined by finding out whether organizations different in
> many ways are the same in that dimension.  On the other hand, it is
> a fact that people have died (and to this day are dying in Japan)
> because of lack of compatibility between communication systems among
> cooperating organizations such as fire and police.  It's possible
> that fallback-to-compatible capability did matter and still does
> matter.

There are ways to provide compatibility without sacrificing security,
however. Read our papers or our (redacted) recommendations to law
enforcement if you wish.

> I'm not going to attempt to deny the importance of security, the
> lack of information and training in use of optional security
> features among users, or the rapid escalation of frequency and
> power of attacks. Nevertheless, advocating extreme security policy
> is unlikely to achieve the goal of extreme security in the current
> environment, and I believe that a more balanced approach can do
> better.

I think that removing SSL 3.0 support is not an "extreme measure" and
leaving it in isn't "balanced" at this point.

TLS 1.0 has been around for a very long time. If you want to argue
that removing TLS 1.0 and 1.1 support is a bad idea since support
has only become 100% universal in the last several years, you have a
case to make -- perhaps it should be another few years until those
are deprecated. Then again, I never suggested removing them right now.

If, on the other hand, you want to argue that getting rid of SSL 3.0
is a problem at this point, then you are arguing de facto that bad
protocols can *never* be removed, and that causing minor
inconvenience to a handful of users is far more important than
security.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > There are ways to provide compatibility without sacrificing security,
 > however. Read our papers or our (redacted) recommendations to law
 > enforcement if you wish.

How many of those law enforcement agencies immediately acted on your
recommendations?  How many still use P25 with unencrypted fallback?

 > I think that removing SSL 3.0 support is not an "extreme measure" and
 > leaving it in isn't "balanced" at this point.

While my credentials in security aren't anywhere near as good as
yours, unfortunately, you are obviously an extremist (note: not
"alarmist") so claims that policies you advocate aren't extreme won't
wash.  They may nevertheless be correct, but I'd rather hear arguments
to that effect

Or better yet, see the experiment with the default switched to refuse
to do SSL 3.0, and actual removal scheduled for the next release.

 > TLS 1.0 has been around for a very long time. If you want to argue
 > that removing TLS 1.0 and 1.1 support is a bad idea since support
 > has only become 100% universal in the last several years, you have a
 > case to make -- perhaps it should be another few years until those
 > are deprecated. Then again, I never suggested removing them right
 > now.

Mac OS X Yosemite still delivers OpenSSL libraries with 0.9.8.

 > If, on the other hand, you want to argue that getting rid of SSL 3.0
 > is a problem at this point, then you are arguing de facto that bad
 > protocols can *never* be removed,

You can catch lots of flies with that kind of horse manure, but you
aren't going to catch agreement by putting words in others' mouths.

 > and that causing minor inconvenience to a handful of users is far
 > more important than security.

What's your evidence that the inconvenience in using Emacs is minor
and the Emacs users affected are a handful?

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Tue, 28 Oct 2014 02:17:00 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> Perry E. Metzger writes:
> 
>  > There are ways to provide compatibility without sacrificing
>  > security, however. Read our papers or our (redacted)
>  > recommendations to law enforcement if you wish.
> 
> How many of those law enforcement agencies immediately acted on your
> recommendations?

Several acted quite quickly. I'm not at liberty to discuss the
details for obvious reasons. That said, we had contacts with a large
number of agencies, and they were very interested in our advice.

>  > I think that removing SSL 3.0 support is not an "extreme
>  > measure" and leaving it in isn't "balanced" at this point.
> 
> While my credentials in security aren't anywhere near as good as
> yours, unfortunately, you are obviously an extremist

Whatever. You can keep calling me names all you like -- but it
doesn't make your opinion any more correct. Indeed, no matter what
names you call people, it won't increase the evidence for your
position.


Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > > While my credentials in security aren't anywhere near as good as
 > > yours, unfortunately, you are obviously an extremist
 > 
 > Whatever. You can keep calling me names all you like -- but it
 > doesn't make your opinion any more correct. Indeed, no matter what
 > names you call people, it won't increase the evidence for your
 > position.

Absolutely correct.  But then I didn't claim it increased the evidence
for *my* position.  I said that it dilutes *your* authority (and you
are an authority AFAICS), in particular when you are claiming that some
particular position of yours is "not extreme".  And that's all I said.

N.B. "Extremism in the defense of freedom is no vice" -- and I
consider contributions to security technology and policy[1] defense of
freedom.  OTOH, extreme policies still need to be justified by the facts.

Footnotes: 
[1]  in the narrow technical sense of "policy", as in "firewall
policy" -- obviously the "security policy" implemented by the border
patrol or whatever they're called these days is not a priori defense
of freedom.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

() "Stephen J. Turnbull" <stephen@xemacs.org>
() Tue, 28 Oct 2014 16:04:12 +0900

   Perry E. Metzger writes:

    > > While my credentials in security aren't anywhere
    > > near as good as yours, unfortunately, you are
    > > obviously an extremist
    > 
    > Whatever. You can keep calling me names all you
    > like -- but it doesn't make your opinion any more
    > correct. Indeed, no matter what names you call
    > people, it won't increase the evidence for your
    > position.

   Absolutely correct.  But then I didn't claim it
   increased the evidence for *my* position.  I said that
   it dilutes *your* authority (and you are an authority
   AFAICS), in particular when you are claiming that some
   particular position of yours is "not extreme".  And
   that's all I said.

It's important to choose precisely between:
- Your words/actions/dissipations are ADJ.
- You are an ADJist.
on TX, because it will surely be distinguished on RX.

[recip clamped]

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Thien-Thi Nguyen writes:

 > It's important to choose precisely between:
 > - Your words/actions/dissipations are ADJ.
 > - You are an ADJist.
 > on TX, because it will surely be distinguished on RX.

Indeed.  But a mailing list is a multicast medium, and in context one
may wish to have a certain effect on some recipients and not care so
much about others' misunderstandings.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

> I consider contributions to security technology and policy[1] defense
> of freedom.

Note that in the context of "secure"boot, digital restrictions
management, and other tivo-ized systems, that same technology is clearly
being used against freedom.


        Stefan

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Tue, 28 Oct 2014 09:31:58 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > I consider contributions to security technology and policy[1]
> > defense of freedom.
> 
> Note that in the context of "secure"boot, digital restrictions
> management, and other tivo-ized systems, that same technology is
> clearly being used against freedom.

There's nothing wrong with things like secure boot systems provided
they're fully under the control of the user. Yes, the same technology
has multiple uses, both pro and anti freedom, but that's true of all
sorts of things, including computers in general.

(I'll point out that given that the NSA "Ant Catalog" includes a
bunch of BIOS-inserted malware and other load-time infection
techniques. Secure booting is actually a priority for ordinary
people. The trick is to make sure it isn't used as an instrument to
prevent ordinary people from booting software of their choice, but
rather is used as an instrument to assure that when they boot the
software of their choice, they're actually getting that and not
malware. Again, you can use most technologies multiple ways.)

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Florian Weimer]

* Perry E. Metzger:

> The trick is to make sure it isn't used as an instrument to prevent
> ordinary people from booting software of their choice, but rather is
> used as an instrument to assure that when they boot the software of
> their choice, they're actually getting that and not malware.

None of the existing boot verification technologies provides this.
It's also difficult to reconcile this with full user autonomy—if the
user can load previously untrusted key material (and especially if
this is an expected step during installation of a free operating
system), the firmware can no longer warn about malicious keys and
malicious software (because the user has replaced the trust root).

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Tue, 28 Oct 2014 16:33:36 +0100 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Perry E. Metzger:
> 
> > The trick is to make sure it isn't used as an instrument to
> > prevent ordinary people from booting software of their choice,
> > but rather is used as an instrument to assure that when they boot
> > the software of their choice, they're actually getting that and
> > not malware.
> 
> None of the existing boot verification technologies provides this.

Agreed. That said, it is important not to throw the idea out entirely
-- don't dump the baby with the bathwater.

> It's also difficult to reconcile this with full user autonomy—if the
> user can load previously untrusted key material (and especially if
> this is an expected step during installation of a free operating
> system), the firmware can no longer warn about malicious keys and
> malicious software (because the user has replaced the trust root).

The user could, however, be in charge of what trusted roots they
accept/load into the firmware, or could hand-enter the hash of the
software they are willing to load. This does not appreciably reduce
security provided it has to be done with physical access to the
machine and is properly designed. (I'm unwilling to produce such a
design on the fly without thinking about it hard.)

My only point was that there are legitimate reasons to want to make
sure you're only loading the code you're expecting to load. Many of
the sorts of technologies being discussed are actually of use. Heck,
Debian signs all their packages at this point to assure
non-tampering -- there is clearly a legitimate use in using
signatures to make sure you're getting what you want. The only issue
is, as you note, that many such systems (see iOS for example) also
prevent you from getting things you might want, which is distinct
from using such systems to assure that you get only what you wanted.

-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stefan Monnier]

[ OK, last message in this offtopic thread.  ]

>> > I consider contributions to security technology and policy[1]
>> > defense of freedom.
>> Note that in the context of "secure"boot, digital restrictions
>> management, and other tivo-ized systems, that same technology is
>> clearly being used against freedom.
> There's nothing wrong with things like secure boot systems provided
> they're fully under the control of the user.

In theory, maybe I could agree.  But so far I haven't seen any use of
secure-boot that helps the user's freedom rather than harms it.

> Yes, the same technology has multiple uses, both pro and anti freedom,
> but that's true of all sorts of things, including computers in general.

My point exactly.

> (I'll point out that given that the NSA "Ant Catalog" includes a bunch
> of BIOS-inserted malware and other load-time infection
> techniques. Secure booting is actually a priority for ordinary people.

How would secure-booting protect the user against BIOS-inserted malware?
A Free BIOS would seem to be much more useful/effective for that purpose.


        Stefan

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Tue, 28 Oct 2014 12:52:55 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > (I'll point out that given that the NSA "Ant Catalog" includes a
> > bunch of BIOS-inserted malware and other load-time infection
> > techniques. Secure booting is actually a priority for ordinary
> > people.
> 
> How would secure-booting protect the user against BIOS-inserted
> malware? A Free BIOS would seem to be much more useful/effective
> for that purpose.

It is necessary but not sufficient to have a free software BIOS. You
also need to make it difficult to modify the BIOS without physical
access to the machine (unless the user has put in a particular jumper
and the new BIOS is signed by a key the user trusts or some such.
There are legitimate applications for remote BIOS upgrades, but not
for normal users.)

Note that there are interesting ways to exploit BIOS code even
without replacing it unless one takes great care -- see, for example,
the recent round of UEFI exploits.

However, as you note, we have gotten far afield from the topic.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Getting the attributions right, I wrote:

 > > > I consider contributions to security technology and policy[1]
 > > > defense of freedom.

And on Tue, 28 Oct 2014 09:31:58 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> replied:

 > > Note that in the context of "secure"boot, digital restrictions
 > > management, and other tivo-ized systems, that same technology is
 > > clearly being used against freedom.

They're being used against *software* freedom.  Without that (or
similar) qualification, it's no longer so clear, as in many cases
other freedoms are being enabled.

Nevertheless, as Perry points out, it's reasonable to consider the
algorithms to be freedom-defending in many cases.  Free software
distributions would be hard put to prosper under current conditions of
criminal behavior on the Internet without signatures, for example.  I
suggest below that the problem is when these technologies are
*embedded* in a hardware product, and the user has no choice about how
they are applied by that product.

Perry E. Metzger rebuts:

 > There's nothing wrong with things like secure boot systems provided
 > they're fully under the control of the user.

Excuse me?  Your main argument in this thread amounts to "'secure
system under the control of the user' is an oxymoron".  That's not
quite true: you personally might be able to pull it off.  But I know
I'm at risk, because I don't have a high degree of expertise.  (I'm
willing to accept the risk because I've learned to be paranoid and
think that the chances that I'll be targeted by a social engineering
threat I don't recognize is low.  But I must acknowledge that risk.)

 > Yes, the same technology has multiple uses, both pro and anti
 > freedom, but that's true of all sorts of things, including
 > computers in general.

Which of course is the argument behind my "consideration" above.
Nevertheless, Stefan and Florian are correct about the technologies
mentioned in current practice.  Furthermore, it's hard to see how it
can be otherwise, since ordinary users do not have access to the
facilities for manufacturing the systems they use, and the convenience
of using systems manufactured by others is huge even if they did.

I'm sure there are ways, but I note that later in the conversation you
acknowledge that it would take a fair amount of thought for you to
design the system itself.  And then there is the politicking and
enforcement against three-letter agencies and wannabe monopolists
necessary to provide a tight legal framework to preserve the freedom
that such a technology would provide.  For the foreseeable future, the
only freedom these particular *embedded* technologies are likely to
defend is that of the manufacturers and their content-marketing
clients.

I note that you and Stefan say that this is getting off-topic, and of
course in one sense you're right.  However, the central tension in the
"rip out SSL3 by the roots" discussion is precisely about whether
users can be trusted not to shoot themselves in the foot enough to
justify the convenience of features that could result in blowing off
their toes.  I think this discussion of freedom-enhancing vs. freedom-
detracting "security" is useful in that context.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Tue, 28 Oct 2014 16:04:12 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> Perry E. Metzger writes:
> 
>  > > While my credentials in security aren't anywhere near as good
>  > > as yours, unfortunately, you are obviously an extremist
>  > 
>  > Whatever. You can keep calling me names all you like -- but it
>  > doesn't make your opinion any more correct. Indeed, no matter
>  > what names you call people, it won't increase the evidence for
>  > your position.
> 
> Absolutely correct.  But then I didn't claim it increased the
> evidence for *my* position.  I said that it dilutes *your*

Name calling is pretty much always a bad idea in a rational
discussion. It adds nothing. Defending it as though it were some
valid form of argumentation is ridiculous.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > Name calling is pretty much always a bad idea in a rational
 > discussion.  It adds nothing. Defending it as though it were some
 > valid form of argumentation is ridiculous.

OK.  Have some valid argumentation:

    So far I have seen "Perry E. Metzger <perry@piermont.com>"
    advocate nothing but extreme positions, often as slogans ("only
    one mode, and that is secure"), without backing them up with the
    relevant facts on *both* sides of the argument so that others can
    judge "the balance" for themselves.  Others, whose opinions I have
    seen to be substantiated in the past, acknowledge that while there
    is some justice to the central claim ("fallback to SSL3 is
    dangerous"), there is also controversy among experts about how
    serious the danger of SSL3 is in various contexts.  Instead of
    addressing that in the context of Emacs, he provides anecdotes
    about unrelated systems, where the danger is obvious to any
    layman, as evidence of how serious things *can* get, but is
    unwilling to provide facts about the actual uptake of his
    recommendations even in these extreme use cases, despite the fact
    that the central vulnerability of his argument is that users will
    choose to avoid upgrades because of the inconvenience of the
    additional security.  I see no reason at present to expect him to
    provide balance in the future or account for other values such as
    user inconvenience in making his assessments, and therefore
    discount his recommendations in spite of his evident technical
    expertise and experience.

    I recommend to others that they be careful of accepting his policy
    recommendations in this context despite his expertise, and demand
    more careful argument than he has provided so far, as so far I
    have seen only extreme policies appropriate for extreme use cases.
    But the policies are not obviously appropriate for Emacs, and I
    don't see a valid analogy to Emacs in the use cases.

All OK now, right?

N.B. As you have probably recognized, the above is argument ad
hominem, and does not directly address the issues involved.  But that
form of argument is appropriate in this case, because the point is
that, despite your expertise, you haven't addressed them either.
Instead, you have relied on the fact of your expertise (argumentum ad
hominem itself!) and a few specious analogies, rather than the facts
of *this* case.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Wed, 29 Oct 2014 11:33:43 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> Perry E. Metzger writes:
> 
>  > Name calling is pretty much always a bad idea in a rational
>  > discussion.  It adds nothing. Defending it as though it were some
>  > valid form of argumentation is ridiculous.
> 
> OK.  Have some valid argumentation:
> 
>     So far I have seen "Perry E. Metzger <perry@piermont.com>"
>     advocate nothing but extreme positions,

Wait, so you're actually doing argumentum ad hominem now? "We can't
believe these arguments because a bad person argues them"?

Really?

FYI, lists of logical fallacies aren't bingo cards. The idea is to
avoid all of them, not to try to hit them all.

> All OK now, right?

No.

> N.B. As you have probably recognized, the above is argument ad
> hominem,

Yes, and thus it is not valid argumentation.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Stephen J. Turnbull]

Perry E. Metzger writes:

 > > N.B. As you have probably recognized, the above is argument ad
 > > hominem,
 > 
 > Yes, and thus it is not valid argumentation.

Look who's arguing by label now!  The argumentum ad hominem is a
fallacy precisely when used to argue a point of fact unrelated to the
specific individuals discussing that point.

But my point is that since most of us don't have a high degree of
technical expertise, your opinions and recommendations as an expert
should be given great weight if they are unbiased with respect to the
Emacs context.  Unfortunately, I think your experience has biased you
in this context, and have argued that point.

I don't know if technically that's argumentum ad hominem, but it sure
looks like it to me.  In either case, it's valid.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Wed, 29 Oct 2014 16:28:58 +0900 "Stephen J. Turnbull"
<stephen@xemacs.org> wrote:
> Perry E. Metzger writes:
> 
>  > > N.B. As you have probably recognized, the above is argument ad
>  > > hominem,
>  > 
>  > Yes, and thus it is not valid argumentation.
> 
> Look who's arguing by label now!

Whatever. When you want to have a discussion which doesn't consist of
insults, ad hominems, strawmen and all the rest, your points might
then be of some value. Regardless, the current form of this
discussion is long since of no interest to the Emacs developers list.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Kurt Roeckx]

On Thu, Oct 23, 2014 at 02:57:21PM -0400, Perry E. Metzger wrote:
> On Thu, 23 Oct 2014 20:43:32 +0200 Florian Weimer <fw@deneb.enyo.de>
> > Keep in mind that TLS 1.0 basically has the same problem as SSL 3.0,
> > and support for protocols beyond TLS 1.0 is not actually widespread.
> 
> Connections to most of the top sites are TLS 1.2 at this point.
> Google is TLS 1.2. Facebook is TLS 1.2. Amazon is TLS 1.2. Apple is
> TLS 1.2. I could go on and on.
> 
> All are using AES at this point and not RC4 as well.

I think this is really getting off topic.  But if you want to see
real stats look at things like:
https://www.trustworthyinternet.org/ssl-pulse/
https://lists.fedoraproject.org/pipermail/security/2014-September/001976.html


Kurt

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Thu, 23 Oct 2014 12:34:38 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> I've read that falling back to ssl3 is a real security hole,
RS> being exploited frequently.  That feature should be removed.

That's not really relevant to the bug report, but with GnuTLS you use
priority strings to control this.  Nikos, the GnuTLS maintainer, asked
for feedback on disabling it in the default priority string in the
mailing list:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7732

If you're using the Emacs GnuTLS integration, you simply set the
priority string through `gnutls-algorithm-priority' to what works for
you; for example "SECURE256:-VERS-SSL3.0". I'd rather wait for the final
decision from the GnuTLS maintainer than change the Emacs default.

If you're using the external s_client, you need to customize its
invocation accordingly.

HTH
Ted

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In an issue of security vulnerability, giving users the right defaults
is paramount.  Allowing users to customize is no substitute.
Most users don't know about the issue.  We need to DTRT for them.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Perry E. Metzger]

On Sat, 25 Oct 2014 03:31:49 -0400 Richard Stallman <rms@gnu.org>
wrote:
> In an issue of security vulnerability, giving users the right
> defaults is paramount.  Allowing users to customize is no
> substitute. Most users don't know about the issue.  We need to DTRT
> for them.

YES. 

My proviso is that I generally think giving them an easy to use knob
to let them do the wrong thing is also a mistake, because social
engineering will often be used to convince them to turn off their
security. If you can't avoid providing the knob, at the very
least, you need to make the default correct and make the knob hard
to turn by accident.

On social engineering: I'm aware of people having been attacked
by having their TLS encrypted connections disrupted by injected
traffic while unencrypted ones were left unmolested. This convinced
the users that there was some sort of problem with the encryption and
that they should drop to the clear by unchecking the "use TLS" box
in their GUI (the implications of which they didn't understand in the
first place). Having done so, their (sensitive) connection and login
credentials were then examined by the attackers. If unencrypted mode
had not been permitted, the attack would not have succeeded. This
was, in effect, a socially engineered downgrade attack.

I recognize that some will again say "but most people face no
such attacks and are doing nothing sensitive", but again, the problem
is that the same software is used in sensitive and non-sensitive
situations. Your software will not psychically intuit that you are a
journalist doing a chat with an Iranian dissident while most
people are just discussing video games with the same chat program.

So, yes, at the very least, the default must be fully secure, but it
is always best that there only be one mode, and it should be the
secure mode. If you need to provide a knob, make sure the user has to
do something inconvenient to get at it.

Perry
-- 
Perry E. Metzger		perry@piermont.com

removing SSLv3 support by default from the Emacs GnuTLS integration (was: Bug#766395: emacs/gnus: Uses s_client to for SSL.)

[Ted Zlatanov]

On Sat, 25 Oct 2014 03:31:49 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> In an issue of security vulnerability, giving users the right defaults
RS> is paramount.  Allowing users to customize is no substitute.
RS> Most users don't know about the issue.  We need to DTRT for them.

(changing subject, since this is not related to the original Debian bug)

The current logic is pretty simple; see `gnutls-negotiate':

         (priority-string (or priority-string
                              (cond
                               ((eq type 'gnutls-anon)
                                "NORMAL:+ANON-DH:!ARCFOUR-128")
                               ((eq type 'gnutls-x509pki)
                                (if gnutls-algorithm-priority
                                    (upcase gnutls-algorithm-priority)
                                  "NORMAL")))))

So there's definitely room for improvement there.  We can, for instance,
make it a per-host choice as we did with `gnutls-verify-error'.  But the
default value is the critical part, as you say.

So let's consider the possibilities:

1) we make the default GnuTLS priority string "SECURE256:-VERS-SSL3.0"
or "NORMAL:-VERS-SSL3.0" without waiting for the GnuTLS maintainer's
decision. This will disrupt many users' experience, especially with
self-hosted services, and may need to be changed again. It's also not
clear that it's the best course of action.

2) we wait 1 week for the GnuTLS maintainer to make a decision and
advise people to upgrade GnuTLS to the new version, adjusting our
default to match theirs.  Please comment in the GnuTLS mailing list with
your opinions.

3) we exclude SSLv3 but somehow detect when a connection is rejected
this way and offer to the user to add an exception for the current host.
This is the most complex solution and will need special care with
non-interactive Emacs runs, but is probably closest to what users
expect.  It's also very close to what Lars and I (and Toke with his TOFU
patch) were thinking of doing for `gnutls-verify-error' and certificate
management, so please review that recent thread.

My proposal is (2) now and to plan to implement (3) in November 2014.
I will dedicate time to (3) and perhaps others will, too.

IMO the work required for (3) should go into trunk and emacs-24, and it
should be a blocker for the next 24.x release. But that's a decision for
the Emacs maintainers. I'll be happy pushing my work into trunk only.

I hope this is a reasonable proposal and would appreciate your comments.

Ted