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