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

[Jimmy Yuen Ho Wong]

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

No, `low` verifies the certificate. That's always been the case, its
just on master, they are separate from the protocol checks. In my
branch, I have broken up the giant and separate
`nsm-check-certificate` function and reimplemented it as 2 check
functions in `nsm-tls-checks`. There's no distinction between
certificate checks and protocol checks anymore, whatever that means
originally. A check for a TLS connection is just that, a TLS check. As
such, `medium` is not minimum, `medium` means default, i.e. verifies
the cert + checking for unsafe TLS extensions and cipher suites.
`high` is `low` + `medium` + checking for more unsafe cipher suites
that are still widely deployed but warning you under most
circumstances may produce excessive nagging (It's getting very rare
these days tho, due to Google and Mozilla flexing their muscles, so to
speak).

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

The answer to this question very much depends on how this intranet is
setup to mirror the most current best practices for the wider
internet. If they are close, as they should be, all you have to do is
give your org's CA PEM file to `gnutls-trustfiles` and you are all
set. If your org only relies on a physical separation, and does not
deploy TLS internally, your connections either go through
`nsm-check-plain-connection` in the case of SMTP/POP/IMAP, which does
nothing unless a previous connection to your internal email server was
done in a TLS connection, or not go through NSM at all. For anything
between these 2 extremes, you can easily adjust the checks in the new
defcustom that is `nsm-tls-checks`, which allows you to insert and
delete individual cons' in the alist in Customize. Expanding the
network security section in the manual to cover what these checks are
and how to adjust them should help users in these orgs figure out what
to do.

> Same questions regarding a home network, separated from the outside
> world by a firewall.
>
> Why shouldn't Emacs cater to such use cases?
>

Do you run your own CA and TLS servers at home? Do you use Google at
home? If you answer no and yes, then the list of checks in my branch
is designed specifically for you.

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

If they know a site might be dangerous a priori and still decide to
visit it, may be The Emacs Way is to treat them like adults?

> 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 think it's good that you are trying to be thorough, but I think you
are over-complicating the situation here. The answer to these
situations can be found by doing what I call "The Google Test" -

Do you use Google on this network? If yes, you need the checks in my
branch. If no, adjust the checks in `nsm-tls-check` as you see fit.
Read the manual to find out how.

For weird enterprise networks, if you get a prompt, you can whitelist
the intranet site by typing a for always, and you don't get a prompt
the next time. I think this is a good balance between convenience and
safety. Lars' good ideas hold up very well here.

If a user wants more convenience, he can write a check function that
distinguishes these network types you speak of. Let the thousand
flowers bloom in the package ecosystem for these things. Emacs only
needs to provide some hooks and a nice interface for them, which is
NSM.

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

Tons of people already put their init files or the entire
`user-directory` in a git repo and share them across installations.
`nsm-settings-file` by default goes into your `user-directory`, they
can very well put it into a git repo.

> Last, but not least, "emacs -Q" will not save any settings nor use
> previously set ones.
>

Not true. The settings NSM saves do not go into your init file or
custom-file. They are by default saved in
user-directory/network-settings.data, and NSM will use the settings
saved there even during emacs -Q.

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

TBH, while `low` may be useful once in a blue moon for testing
purposes, I can't think of anything that can justify a `paranoid`
level that is not better served by unplugging your network card. But
do let me know if you can think of some.

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

If I understand the code in `network-stream-open-starttls` correctly,
you won't even be able to establish a connection if neither GnuTLS is
linked into Emacs nor a `starttls-command` is available.

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

TLS is protocol agnostic protocol. If the way Emacs implements TLS has
a vuln, the vuln will show up for all connections for all protocols
when a user opens a network stream that requires TLS or STARTTLS.

> Isn't it true that
> some of the vulnerabilities are only or mainly specific to some
> protocols or even some classes of servers?

For the protocols TLS is wrapping, no. For servers, maybe. I'm quite
certain that a lot of schools have woefully outdated TLS settings for
SMTP/POP3/IMAP. For those types of servers, you may get a prompt from
NSM per the default settings. But then again, you can easily whitelist
the cert after visually verifying it. It's fire-and-forget, done once
over the lifetime of the network-settings.data file type of deal.
After that, NSM will protect you if you are served a different cert
identified by its public key ID when connecting to a host previously
visited. In such circumstances, you might be under an active MITM
attack, hence the warning prompt again. All of the checks in
`nsm-tls-checks` is there to prevent MITM, so if you are connecting to
a server that NSM considers unsafe due to outdated TLS settings,
giving you a warning is exactly the right thing to do as opposed to
silently ignoring the problem by relaxing the constraints.

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

Different application protocols contain different kinds of attack
vectors, that's true. But those application-specific security measures
are not the job of TLS. TLS stands for Transport Layer Security, it's
primary jobs are verifying the identity of the server you are
connecting to, ensuring the traffic to that server has not been
tempered and keeping the traffic confidential, that is to say, only
the client and the server can read the messages. TLS' primary function
is to prevent MITM attacks, which contains passive attacks such as
eave-dropping, or active attacks such as phising. Deploying TLS it's
only one of the many security measures for an application. In addition
to TLS, browser have Single-Origin-Policy, Content-Security-Policy,
HTTP-Strict-Transport-Security and a whole host of other techniques to
achieve defence-in-depth. Email clients typically employ spam-filters,
heuristics to detect phising emails, blocking Javascripts and loading
of tracking images. With that said, if we cannot secure the
communication channel, all hopes are lost as a lot of things the
attackers want by launching these application specific attacks are
easily obtainable by intercepting your connection.

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

There are all kinds of github integration packages on Melpa. I think
they tend to clone repos using HTTPS because it's permeable to
firewalls.

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

This only requires deleting 2 lines of comments and s/256/nil, and
perhaps say a few words in the docstring to let users know under what
circumstances should they be adjusting `gnutls-min-prime-bits`. All of
which takes 5 mins maximum. I guarantee you this will cause no problem
whatsoever. If a user has customized `gnutls-min-prime-bits`, changing
the default will have no visible effect to them. For those who
haven't, it's a small step towards having Emacs's network security
catching up to 2015. This is a super-low-hanging fruit. Users will
applaud you if you do this for Emacs 26.2.

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

I'm beginning to think this is probably a good idea.

> Thanks again for working on this.

Thank you for your thoughtful responses!