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

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <address@hidden>
> Date: Fri, 6 Jul 2018 07:42:22 +0100
> Cc: Lars Ingebrigtsen <address@hidden>, Paul Eggert <address@hidden>,
>       Emacs-Devel devel <address@hidden>,
>       "Perry E. Metzger" <address@hidden>
> 
> Whoa that's a lot of emails in one day! I understand that some of you
> are concerned, I am too, that's why I raised this issue. Now, given
> the volume, I don't want to respond individually, so please allow me
> to summarize and address all of your concerns here.

Thanks.

> instead of arguing the issue on moral ground, I propose we look at
> our common grounds and see what we've already agreed on.

Agreed.  I only responded "on moral grounds" because my views were
challenged on those grounds.

> Most of the checks are on `medium` level because of **secure by default**
> ---------------------------------------------------------------------------------------------------
> **Secure by default** is a mantra used by InfoSec professionals, in
> Emacs' lingo it means reasonable default settings. The reason 13 out
> of 17 checks in my branch are on `medium` level is *not* because I'm
> trying to mold NSM to such a way that its **security levels** are
> indistinguishable with **secury level**, but because most of those
> checks are RFC 7525's recommendation's for securely using TLS on the
> client. RFC 7525 is listed as BEST CURRENT PRACTICE by IETF in 2015. I
> have added a couple more checks to `medium` because things have
> evolved since 2015. The details for their inclusion are in the
> docstrings.
> 
> As to `high`, those 3 checks ideally should be included in `medium`

I'm still questioning how can this be TRT.  Please remember that
'medium' in Emacs really means 'minimum', because 'low' has no
security checks at all.  How can it make sense to have _all_ the
checks on the _minimum_ level?  (I say "all" because you clearly think
'high' and 'paranoid' should be removed, and their checks, those which
make sense, moved into 'medium'.)

Suppose I work in Emacs on an internal secure network that is
physically disconnected from the Internet (many enterprises, including
my daytime job, have such stand-alone networks as a matter of
routine).  Why would I need all the checks you propose on such a
network?  OTOH, I don't want to go to 'low' (i.e. 'none') on such
networks, because who knows what viri and other calamities can be once
in a blue moon present on some of the machines on that network.

Same questions regarding a home network, separated from the outside
world by a firewall.

Why shouldn't Emacs cater to such use cases?

On the other end, there are legitimate use cases where users might
need to access sites and servers known in advance to be dangerous.
Why shouldn't Emacs provide a 'paranoid' set of settings for such use
cases?

The RFCs you cite and the vulnerabilities they describe should IMO be
carefully analyzed, in the context of typical Emacs jobs that require
network connections, and then we should grade them by their
importance, divide them into 3 or 4 meaningful classes (a.k.a.
"levels"), and let users change their settings in meaningful ways by
changing the level.  Fine-grained settings should IMO also be
provided, but they cannot be the only solution that we offer our
users, precisely because not everyone has time to study each
individual feature, but they normally will have time to read a
description of 3 to 4 levels and decide which one is for them,
especially if we describe them in terms that are related to the
general environment rather than to specific vulnerabilities, similar
to how many laptops ask you to select whether the new connection is
for "home network", "enterprise", or "public network" -- that's
something that every user can normally answer.

> More checks does not mean more inconvenience
> -----------------------------------------------------------------
> NSM will only prompt you when a check fails *AND* these failed checks
> for a host have not been saved as exceptions. If you answer "session
> only" after the prompt, NSM will not prompt you again until you
> restart Emacs. If you answer "always", NSM will not prompt you again
> for those failed checks for that host as long as the exceptions are
> still saved on file. The ability of having a "chance to choose between
> the alternatives (convenience and safety) early enough that they won't
> beunsafe.  The choice should come with an explanation of each option,
> first stating what situations it is recommended for, then what it
> does." is already implemented in master.
> 
> Having said that, NSM currenly may prompt you many times if there is
> more than one security check failures, i.e. if your level is set to
> `high` and the server such as Google's is load balancing TLS
> connections with 2 or more certs with different fingerprints, and it's
> using SHA1 signatures, you will get 3 prompts. I have streamlined all
> of those in my branch so you only get prompted once for all the
> problems found. That's **more** convenience and "more" safety. You can
> have your cake and eat it too.

These improvements are good (provided that they indeed work in
practice -- I will have to try them), but IMO they are not enough.
You assume each one of us has only one Emacs installation, with only
one HOME directory where settings are saved.  But that is profoundly
not true: people have Emacs installed on several machines, with HOME
directories not necessarily shared.  Emacs developers might very well
have several HOME directories on the same machine, for testing
purposes (I certainly have such setups and use them all the time).
Last, but not least, "emacs -Q" will not save any settings nor use
previously set ones.

That is why IMO we must make the default level strike a reasonable
balance between "more checks" and "convenience".  It is IMO
unreasonable to base such a balance on the assumption that a dedicated
team of thugs with torture chambers are out there to get every one of
us.  I think these cases are a minority, which should be catered to by
non-default security levels -- that's where 'high' and 'paranoid'
should come into the play.

> The `paranoid` level is security theatre.

If the 'paranoid' level doesn't do a useful job, it should be modified
to do a useful job.  The decision whether we even need such a level
should IMO be one we take _after_ classifying the vulnerabilities and
their prevention measures, not before.  It is quite possible we will
decide that we don't need such a level, but the fact it is not useful
today doesn't mean it cannot be useful.

I would very much like the security experts we have in our ranks help
us make these decisions by using their expertise to produce such an
analysis of the issues.  Then this whole discussion would be much more
constructive, and I believe agreements could be reached much faster.

> 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 what you say cover Emacs built without TLS support, for example?

> Emacs is not (only) a browser, but that's a moot point
> -----------------------------------------------------------------------
> Emacs' use base is diverse. People not only browse the Web with it,
> but read and reply to emails, browse newgroups, chat on
> IRC/Jabber/Slack, push code to Github etc., all of which require the
> network to be secured with TLS. While TLS is mostly used on the Web
> because of HTTPS, SSL/TLS has been mandatory for Gmail for many years
> now, Github also requires TLS for code push, and so do many chat
> servers. The way Emacs has deployed TLS either has a fault or it
> doesn't, it doesn't matter which protocol TLS is wrapping over.

I don't see how your conclusion necessarily follows from the fact that
most or all protocols we use are secured with TLS.  Isn't it true that
some of the vulnerabilities are only or mainly specific to some
protocols or even some classes of servers?  Is it really true that,
say, fetching and sending email on the one side, browsing s Web page
on the other, and chatting on the third, all bump into the same set of
risks?  This is the kind of analysis I'd like to see before we make up
our minds what should be in 'medium'.

(Btw, is Github relevant to the issue at hand?  We access Git
repositories by invoking Git, we don't access them from Emacs
directly, AFAIK.)

> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2

As I already said, this will delay the release of Emacs 26.2 by many
moons.  From my POV, doing so is not a good idea, as we already have
quite a few non-trivial bugfixes on the emacs-26 branch, but if no one
else is bothered, I'm fine with doing that.

IOW, this is a project-management decision, not a security-related
decision.

> OpenSSL is nice, but getting much improved network security out the
> door ASAP is nicer
> ----------------------------------------------------------------------------------------------------------------------
> While OpenSSL certainly has its advantages, it is also a much bigger
> target. When dealing with security issues, one has to consider the
> economics. When economics are factored, an attacker will often ask if
> it make sense to spend a month working on an attack to target a small
> user base such as GnuTLS'. The answer to that is likely to be false.
> But if we are on OpenSSL, any new attack targeted towards it will make
> Emacs a target as well.
> 
> In addition, these days I try to live by a motto - Don't let the
> perfect be the enemy of the good. Replacing GnuTLS with OpenSSL is
> significantly harder than writing a couple C functions to get the most
> out of GnuTLS. Replacing it without major regressions even harder.
> Besides, most of Emacs' network security problems do not come from it
> use of GnuTLS, but deficiencies in NSM. I believe Emacs' network
> security can get much better faster if we focus our efforts on the
> current design.

Agreed.

> Documenting security changes
> -----------------------------------------
> Currently, Emacs' network security settings are poorly documented and
> widely misunderstood. There's only one page on the entire Emacs manual
> that briefly describes the checks NSM has, but it doesn't mention what
> its relation is with GnuTLS. There is also no mention of NSM or GnuTLS
> in the Emacs Lisp Reference whatsoever.

NSM documentation that exists was adequate when the number of features
it provided was small, which is what we had until now.  With a vastly
larger number of checks and customization opportunities, the
documentation we have is entirely inadequate, and we must extend it.

> I aim to improve it, but given the amount of work involved to bring
> Emacs' network security up to date, I'd rather submit another patch
> when the dust has settled.  (*cough* feature creep *cough*)

IMO this is a mistake, and I urge you to reconsider.  While there's no
need to follow up each code change on a scratch branch with a suitable
documentation change, I think we already have a lot of added turf to
document, and having at least that well documented will go a long way
towards the goal.  It could even make this discussion more efficient
and more rational, since we would all be on the same page wrt the
issues being discussed, even though not all of us are experts on these
matters.

Thanks again for working on this.