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

[Jimmy Yuen Ho Wong]

On Sun, Jul 8, 2018 at 4:13 PM Lars Ingebrigtsen <address@hidden> wrote:
>
> Jimmy Yuen Ho Wong <address@hidden> writes:
>
> > I still haven't heard of a "good reason" yet.
>
> It's been stated in this thread that somebody uses it and finds it
> useful, and I think that's sufficient.
>

Anybody will find anything useful, that's not a sufficient reason to
throw everything into Emacs, especially when it comes to security.

Finding it "useful" without any reason it's like saying oh this
theatrics makes me feel safer. But are you really? I would remind you
about "security fatigue" again.

Also, for people who are not well-education in security matters,
`paranoid gives them a false sense of security, where in fact it does
nothing more than checking if you've visiting a site before. Why would
having visited a site before make me safer? Allow me to quote myself:

"Why is attempting to securely connect to a server by using a
protocol that will authenticate it a cause for concern? Connecting to
a server via TLS does not mean the user start transmitting
confidential data immediately. That act  comes when you sign up or log
in. That's not TLS's job.

For STARTTLS, if the server does not support TLS, you will have gotten
a prompt for using a plain connection already, so why the extra
prompt? Does it not give the user a false sense of more security? Will
it mislead some innocent user to belive every host can be trusted
under `paranoid` level? If the answer to the last 2 questions were yes, I
believe removing `paranoid` and its check is the right thing to do,
even if only for the sake of giving the right expectation."

Offering an extra paranoid level cause more misunderstanding than
anything else. Bad UI is also a major cause of insecurity. You can
take it from a guy who used to work on the front-end at Cloudflare.

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

Think about this: If I'm connecting to a server that will only offer
256-bit prime, and I've set `gnutls-min-prime-bits` to 256, min means
lower bound, what exactly do I mean?

Setting `gnutls-min-prime-bits` to 256 as the standard value suggests
to me that Emacs' network security level is so relaxed that a TLS
connection with a DH prime 256-bits should go through, but in reality
NSM still warns. This yet again contradicts the intention of the
standard value. If the intention is to warn about prime-bit < 1024
bits, `gnutls-min-prime-bits` should not be 256, otherwise NSM should
not warn.

Just switch it back to `nil` and let GnuTLS do the right thing
according to the priority string for crying out loud. This also has no
adverse effect.

I don't know why I have to keep arguing this issue. The right decision
is clear as day. There is absolutely no reason to set it to 256 by
default in 2018. According to SSLLab's SSLPulse report, there's
exactly 0 server demanding DH < 512 bits. If you absolutely need DH <
512 bits due to some weird corporate network setup, there will be a
new knob called `nsm-trust-local-network`. Otherwise you can set it to
256 manually. Defaulting it to 256 was never a good idea.

If you are thinking about renaming the "Default" tag in
`gnutls-min-prime-bits` 's defcustom, don't. I will start doubting
whether you are doing this under good faith.

Please do not make figuring out how to tune Emacs' network security
setting more confusing than it is already.

>
> I don't think we would get a bug report for that.  People deal with
> "broken" web site TLS all the time, and there'll be an abundance of them
> over the next years.  That's what the NSM is for, and that's not
> something users will complain about.
>

Assuming people understand what the hell NSM is doing. Given the
Reddit thread and this thread, do you think people understand? One of
the goals when designing NSM should be to warning only when it's
appropriate to avoid security fatigue. No more, no less. That doesn't
sound like what you have in mind.