[Top][All Lists]

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

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

From: Jimmy Yuen Ho Wong
Subject: Re: A couple of questions and concerns about Emacs network security
Date: Sun, 8 Jul 2018 15:54:24 +0100

> 1) I don't think the `paranoid' setting is security theatre.  It's not a
> useful setting for general browsing, but if your use case is that you
> only use Emacs for, say, talking with your IMAP server, and that's it,
> and you're worried that you may somehow end up talking with the wrong
> server, and you're, er, paranoid (perhaps with good reason), then
> that's the setting for you.

I still haven't heard of a "good reason" yet. If the checks are
complete on the 'high level (i.e. checks for all known problems,
including checking your cert for revocations with OCSP+CT+CRL, use of
interceptable static RSA key exchange...), it would require some sort
of zero-day to forge a cert. Honestly if you are in that kind of
hostile environment, using Emacs to check your email directly without
connecting to a VPN first is an absolutely horrible idea. If you are
in that kind of environment, you would know it.

> But, yes, as Eli says, `paranoid' should perhaps do more for non-TLS
> connections.  The question is "what", though, because there's no
> fingerprint (beyond the host/port number) that we can use to verify
> that a non-TLS connection is to a previously seen host.

Exactly. NSM can only warn you if you are establishing a cleartext
connection, nothing else can be done.

> I thought that it set the minimum number of bits (like it says in the
> last sentence), but it would use however many bits the server allows.
> The first sentence seems to contradict this, and that this sets an
> upper as well as lower bound on the number of bits, which is pretty
> horrific, if that's the case...  But I don't think it is, because
> I get ":diffie-hellman-prime-bits 2047" when connecting to a DH host.

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.

BTW, this bahavior pretty much we can default `gnutls-min-prime-bits`
to nil with no problem at all as we haven't seen any bug complaining
about NSM checking for DH prime bits > 1024 being too strict.

I would suggest we move the defcustom groups of all GnuTLS options to
NSM again to avoid further confusion.

reply via email to

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