bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 18 Mar 2014 22:04:08 +0100 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> I see three partially contradictory requirements here:
JL> 1. No interactive prompting.
JL> 2. Allow self-signed certificates.
JL> 3. Protect against MITM attacks (at least those involving
JL>    self-signed forged certs; better yet, also with “trusted” forged
JL>    certs).

JL> Among those three, at most two can be guaranteed simultaneously.

Right, of course.  That's the challenge.  Oh, and it must work for
everyone out of the box without ever checking release notes and the
manual :)

I think the self-signed certificates are the one we can omit, it's a
fairly rare use case.  We can provide a *simple* certificate manager UI
to list, display, and add/modify/remove certificates to make it easy,
but otherwise we can reject these with a suitable message "this
certificate can't be verified; to accept it run COMMANDHERE SITEHERE".
The certificate manager UI could do the TOFU interaction.

Once we have that we can reject unverified certificates, after 24.4 is
out.  Until then it has to be nil by default IMO.

JL> From http://debbugs.gnu.org/13374 I got the impression that (2) is a
JL> must.  (I rely on self-signed certs as well.)  In addition, in my
JL> view (3) is a must.  Others may disagree and choose the convenience of
JL> (1) over the security of (3).  If Emacs defaults to (1) over (3)
JL> based on a deliberate decision, that decision needs to be documented
JL> prominently.

JL> Coming back to your comment, I believe that --strict-tofu satisfies
JL> precisely what you describe: It aborts the connection, and you can
JL> add the new certificate with --tofu.

>> Can you suggest a cleaner way, perhaps using TOFU
>> with some C automation?

JL> I’m not really sure what you are looking for.

You provided the workflow above.  Now the question is, how can Emacs
implement it in a way that works interactively and non-interactively?

For storage of the certificates, I think
~/.emacs.d/certs/hostname.somextension is the right place.  I asked this
on gnutls-devel a while ago so we can revisit the discussion when we
have the UI worked out.

For the UI I suggested a certificate manager mode.  Maybe that's
overkill, I don't know.

>> I appreciate all your review.  It's too late to make these changes for
>> 24.4, but I think if you can review the state of things in 24.4, maybe
>> we could discuss an expedited 24.5 release with security fixes (that
>> would be up to the Emacs maintainers, of course).

JL> I’ll certainly work with 24.4.  Just let me know what kind of input
JL> you need then.

How to automate the TOFU, so far.

JL> I don’t see `gnutls-serv'.  The following works for me:
JL> (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")

JL> It also catches MITM attacks with self-signed certs:
JL> (error "Certificate validation failed imap.gmail.com, verification
JL> code 66")

JL> That’s good.

Wonderful!

JL> P.S. Self-signed certs are unusable now, e.g., this fails:
JL> (open-gnutls-stream "tls" "tls-buffer" "news.gmane.org" "nntps")
JL> Of course, this is to be expected, but Gnus aborts the connection
JL> without any user-visible clue, and the server is reported to be
JL> offline.

Hmm.  That seems a Gnus bug :) Can you submit it separately, to keep the
books clean, after testing with the latest Gnus?

JL> P.P.S. I’m using imap.el, which knows of various ways to establish
JL> SSL/TLS connections, but gnutls.el is not among them.

I think you're on an old Gnus then, which is strange considering you're
testing with a recent Emacs.  What's `M-x gnus-version'?

Ted