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

[Ted Zlatanov]

On Mon, 10 Mar 2014 07:52:43 +0100 Jens Lechtenboerger 
<jens.lechtenboerger@fsfe.org> wrote: 

JL> I don't find that acceptable.  I vote to ship Emacs with certificate
JL> checking by default.

Hi Jens,

that's how it's planned, but please realize we have to be careful with
the large population of Emacs users that would be surprised by sudden
failures.  So 24.4 is the first version where we'll start doing this.

JL> gnutls-cli --tofu opens a TLS connection and asks whether the
JL> certificate can be trusted.  If so, it is added to
JL> ~/.gnutls/known_hosts.  On subsequent connections, the presented
JL> certificate is compared against the stored one; in case of
JL> mismatches, the user is asked whether to trust the new one.  To
JL> prevent the process from hanging while waiting for the user's reply,
JL> option --strict-tofu (introduced in GnuTLS 3.2.12) can be used.
JL> I'm describing my view on certificate pinning in general and some
JL> details on TOFU with GnuTLS in more detail in my blog:
JL> https://blogs.fsfe.org/jens.lechtenboerger/?p=208

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.  Can you suggest a cleaner way, perhaps using TOFU
with some C automation?

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

JL> For Emacs, here is my personal workaround (a real fix would
JL> probably require a unified, secure-by-default treatment of TLS
JL> throughout all libraries):

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

Thanks
Ted