emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC] GnuTLS: Support TOFU certificate checking.


From: Lars Magne Ingebrigtsen
Subject: Re: [PATCH RFC] GnuTLS: Support TOFU certificate checking.
Date: Wed, 08 Oct 2014 13:53:35 +0200
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)

Toke Høiland-Jørgensen <address@hidden> writes:

> Right, I can definitely see the point of that, and ultimately this is
> definitely desirable. The GnuTLS TOFU mode could be a way to do the
> heavy lifting of certificate fingerprint storing and verification etc.
>
> I don't think I'm sufficiently familiar with the innards of
> open-network-stream to implement this, sorry. However, if you agree this
> could be a reasonable building block for the user-facing functionality I
> could rework the patch to (a) signal an appropriate error code when
> verification fails and (b) add a parameter to add the certificate to the
> trust chain. The lisp code could then use this functionality (by passing
> the appropriate parameters to gnutls-boot) to implement the user-facing
> y/no/maybe/whatever on top of it.

Yes, that's what the Emacs gnutls code needs: A way to access the
certificate, and the verification status of that certificate (i.e.,
whether it managed to validate it or not, and if not, why not).

Then the management of this could be done at a higher level, which would
be `open-network-stream'.

> Also, I'll add that TOFU can also be used to ensure stronger trust than
> just checking that the certificate validates; it can also be used for
> certificate pinning to ensure that it doesn't change. This is what I use
> it for personally, and I consider it a nice added security...

Yes, `open-network-stream' would implement certificate pinning.  That
is, it would store a fingerprint of the certificate and query the user
for what to do when that changes.  It would also use that to keep track
of whether a STARTTLS connection suddenly starts not offering STARTTLS,
which would be a typical symptom of a man-in-the-middle attack filtering
out the STARTTLS dialogue from the server.

If you implement the C gnutls bits, that would be great.  Then somebody
else (ahem, probably me) could do the `open-network-stream' bits...

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]