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 14:03:51 +0100
> Cc: address@hidden, Lars Ingebrigtsen <address@hidden>, Paul Eggert 
> <address@hidden>, 
>       Emacs-Devel devel <address@hidden>, "Perry E. Metzger" 
> <address@hidden>, 
>       Robert Pluim <address@hidden>
> 
> No, `low` verifies the certificate.

Thanks.  I was looking at nsm.el, so I guess I missed that.

Still, I'm asking whether it is appropriate to check only the
certificate.  Aren't there any other checks that would fit 'low'?

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

I'm saying that it would be good to have a single setting in Emacs,
ideally one of the security levels, that I could use in such
environments, without being bothered about the details.

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

Sorry, I don't understand what that means in practice.  Are you saying
that on your branch Emacs doesn't by default distinguish between such
home networks and public connections to Internet?  If so, I don't
think it's TRT.

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

There could be legitimate use cases for that.  For example, testing
nsm.el ;-)

> I think it's good that you are trying to be thorough, but I think you
> are over-complicating the situation here.

I might agree with you, but not before we see the details of some of
these "complications".

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

Can you explain how a single site can be used to decide on what checks
are appropriate?

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

See, I'm getting these prompts from Firefox too frequently, and I'd
hate Emacs to do the same.  Even if these prompts are shown only once
for every such site.

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

We are talking about the defaults, so let's not start about fancy
customizations.  Selecting a non-default security level should be the
only customization pertinent to this discussion.

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

Hmm... I would consider this a bug, as it means "emacs -Q" behaves
differently on different systems and with different users.

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

Robert just did, see his post.

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

So we prompt for a plain connection when TLS is available, but
unconditionally fail it when TLS isn't available?  Does that make
sense?

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

TLS is protocol agnostic, but vulnerabilities aren't, right?  I mean,
some of the vulnerabilities are more likely (or even only) met when
using TLS with some protocols and not with others, right?

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

That might be "good enough", but I'm still not convinced that we
cannot do better by default.

> In such circumstances, you might be under an active MITM attack,
> hence the warning prompt again.

Yes, I might, but is it reasonable to have the defaults assume
_everyone_ is _always_ under such an attack?  I don't think so.

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

The NSM is not only about TLS, it's about any network connection Emacs
establishes.  The security levels should not be only about TLS.

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

I'd be surprised if any of those packages used HTTPS to access Git
repositories.  They'd have to reinvent Git.

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

I didn't say the change is complex.  What bothers me is entirely
different effects this change could have.

> I guarantee you this will cause no problem whatsoever.

Sorry, I cannot accept such guarantees.  I have too much gray hair.

> Users will applaud you if you do this for Emacs 26.2.

Been there, done that, can show the scars.

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