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

[Jens Lechtenboerger <jens.lechtenboerger@fsfe.org>]

On 2014-03-17, Ted Zlatanov wrote:

> On Mon, 10 Mar 2014 07:52:43 +0100 Jens Lechtenboerger
> <jens.lechtenboerger@fsfe.org> wrote:
>
> JL> gnutls-cli --tofu opens a TLS connection and asks whether the
> JL> certificate can be trusted.
> JL> [...]
> JL> to prevent the process from hanging while waiting for the
> JL> user's reply, option --strict-tofu (introduced in GnuTLS
> JL> 3.2.12) can be used.
>
> That's wonderful, but please realize this doesn't work for Emacs because
> often, interactive prompting would not be available.  The consensus so
> far has been to abort the connection and tell the user how to allow a
> host specifically.

Hi Ted,

are you outlining plans for the future?  According to what I
observed so far, I’m either vulnerable to MITM attacks or I cannot
use servers with self-signed certificates.

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

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

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

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

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

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

> (`gnutls-cli' should not be assumed to be available)

Sadly, that’s true.  But it could (a) be recommended and (b) be used
if it is available (and (c) be used in a safer way).

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

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

Best wishes
Jens