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

[Robert Pluim]

Eli Zaretskii <address@hidden> writes:

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

Thatʼs not quite my reading. Jimmy says:

  until RSA KX, DHE KX and CBC
  ciphers go away completely from the servers, I believe putting them on
  the `high` level is appropriate.

so, it not a proposal to move them now. By the time that can be done,
I suspect there will be other checks that can be added into
'high'. And most checks *should* be on 'medium', since many people will
never change the defaults.

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

Current security thinking no longer makes a distinction between
'internal' and 'external' networks, they're all assumed to be
potentially dangerous, so 'low' would never be appropriate (except for
honeypot type activities).

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

I have such a network at home. I also have family members who are not
necessarily as aware of security issues as I am, and who also possess
network connections that are not secured by my 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?

That I agree with, and thatʼs why I use 'paranoid', limited as it
currently is.

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

I donʼt think this is the right approach: the defaults should be as
secure as we can make it whilst remaining reasonably convenient. I see
no real use case for 4 separate classes that could meaningfully be
used by a typical user (as distinct from 'low', 'paranoid', and the
fine-grained settings, all intended for experts).

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

Iʼm not sure what youʼre proposing here.  These settings are per-HOME,
as all emacs settings are. Did you want some method for sharing the
NSM settings?

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

Even people not in physical danger deserve to have their
communications protected from interception and snooping, as part of
the basic human right to privacy and freedom from unjustified
governmental tracking of their online behaviour.

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

Thatʼs an excellent question to which I donʼt have an answer, although the
'open-network-stream' doc-string has:

  `starttls' -- Begin with an ordinary connection, and try
                upgrading via STARTTLS.  If that fails for any
                reason, drop the connection; in that case the
                returned object is a killed process.

and

  :use-starttls-if-possible is a boolean that says to do opportunistic
  STARTTLS upgrades even if Emacs doesn't have built-in TLS functionality.

So perhaps we should ensure that all uses of it in emacs use that one
or both of those where reasonable (the docstring for that function is
long and complex, and all the possible interactions of various tls
options are not obvious to me).

As an aside, we should really try to steer people away from both
cleartext *and* STARTTLS connections towards using direct TLS
connections, but Iʼm not sure what the right method is there.

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

That might be going a bit far, but I can certainly do that locally and
see what happens.

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

26.1 is out there. 26.2 has some fixes, but I see nothing that
requires a quick 26.2 release (but my perspective is skewed by the
fact that I build from git anyway).

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

Documentation is good. Iʼll see if I can find some time to work on
that.

> Thanks again for working on this.

Likewise.

Regards

Robert