Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 6:53 PM Eli Zaretskii <address@hidden> wrote:
>
> > From: Jimmy Yuen Ho Wong <address@hidden>
> > Date: Sun, 8 Jul 2018 17:56:03 +0100
> > Cc: Emacs-Devel devel <address@hidden>
> >
> > > > That's true, but there's still no reason to default
> > > > `gnutls-min-prime-bits` to 256. If that's the default, presumably
> > > > checking for DH prime bits > 1024 is a bug as NSM should let 256-bit
> > > > DH prime go through.
> > >
> > > No?  We let gnutls always establish the connection, no matter how sucky,
> > > and then we ask the user about it.  That's the whole idea behind the
> > > NSM.
> >
> > No we don't let GnuTLS always establish the connection. We don't set
> > the priority string to the lowest level possible, i.e. "LEGACY". Are
> > you suggesting you want to do that?
> > The precedence has been set that we don't allow every GnuTLS
> > connection to go through, therefore, your ideal with letting NSM
> > handle all kinds of network security issues in Emacs is invalid.
> >
> > > And setting gnutls-min-prime-bits to 256 has no adverse effects, since
> > > (contrary to what you've said several times in this thread), the TLS
> > > connection will use as many prime bits that the server offers,
> > > apparently.
> > >
> >
> > The adverse effect is, there is no way to explain this clearly to a
> > user WTF is going on without confusing the hack out of people. The
> > choice option with a "Default" :tag in the defcustom already says nil
> > is the default, just the standard value isn't. This is already a
> > contradiction.
>
> But if we set the prime bits to a higher number, isn't it true that a
> TLS connection will fail with little or no explanations?  Whereas the
> NSM does provide a sensible description of the problem when it asks me
> whether to go ahead with the insecure connection, so I could consider
> how much I trust the server and/or the connection.
>
> I don't know if I'm talking about the same situation, but I sometimes
> get from Firefox a cryptic "secure connection failed" with some error
> code mnemonics I don't understand; when that happens, it annoys me
> quite a bit, because I have no easy way of figuring out whether the
> problem is with the server, with my box, or with some fascist
> firewall in the middle.
>
> If this is what will happen when we bump the number of bits (or with
> any other security setting), then I'd rather have NSM catch that and
> talk to me in a language I can understand better.  At least as an
> option, if not by default (and no, that option shouldn't be
> gnutls-min-prime-bits, as that's too technical for most users; I'm
> thinking about some non-default security level, perhaps).
>
> Does that make sense?
>
> > Just switch it back to `nil` and let GnuTLS do the right thing
> > according to the priority string for crying out loud.
>
> If you mean that people should customize the priority string, then I
> think this is again too technical and shouldn't be the primary
> solution we provide users for controlling their security level.

No, I'm saying don't override GnuTLS's defaults by default (geeez
that's a lot of defaults, hope that makes sense). If people want to
enable certain things the GnuTLS doesn't allow by default, they can
still do it by adjusting GnuTLS's priority string. The priority string
is GnuTLS's primary means for adjusting its feature set.

"The GnuTLS priority strings specify the TLS session’s handshake
algorithms and options in a compact, easy-to-use format. Thee strings
are intended as a user-specified override of the library defaults.

That is, we recommend applications using the default settings (c.f.
gnutls_set_default_priority), and provide the user with access to
priority strings for overriding the default behavior, on configuration
files, or other UI. Following such a principle, makes the GnuTLS
library as the default settings provider. That is necessary and a good
practice, because TLS protocol hardening and phasing out of legacy
algorithms, is easier to co-ordinate when happens in a single library.
"[1]

The way we use `gnutls-min-prime-bits` is also problematic, as the
docs suggests that it's been deprecated since 3.1.7. [2]

In order to throw the error back out to LISP to NSM to check when the
server presents a prime bit that's too low, we can catch the
GNUTLS_E_DH_PRIME_UNACCEPTABLE error. This is trivial judging from the
C code.

[1]: https://www.gnutls.org/manual/gnutls.html#Priority-Strings
[2]: 
https://www.gnutls.org/manual/gnutls.html#gnutls_005fdh_005fset_005fprime_005fbits