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

[Eli Zaretskii]

> From: Robert Pluim <address@hidden>
> Cc: Jimmy Yuen Ho Wong <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden
> Date: Fri, 06 Jul 2018 11:28:24 +0200
> 
> 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.

Not now, indeed, but only for temporary practical reasons:

> As to `high`, those 3 checks ideally should be included in `medium`

I was referring to the general tendency, which is quite clear.

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

I agree that the defaults should be reasonable for that reason.  My
problem is with the "most" part: I'm not yet convinced it is TRT.

> Current security thinking no longer makes a distinction between
> 'internal' and 'external' networks, they're all assumed to be
> potentially dangerous

I question the wisdom of such security thinking.  The security officer
on my daytime job clearly disagrees with that.  (Cannot tell the
details here, because there will be too many people I'll have to take
out and shoot afterwards ;-)

> so 'low' would never be appropriate (except for honeypot type
> activities).

In Emacs, 'low' is actually 'none'.  Which is an other thing that
makes little sense to me.  I know of no other application whose
default security level is one notch above no security at all, they all
provide a "less secure" level.

So yes, I agree that 'low' in Emacs is almost never appropriate, but I
agree for entirely different reasons.

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

So your network may be less secure than my home network, where only
machines and devices to which I explicitly allow access can connect.
It's legitimate to have home networks of different security standards.
What I think is not optimal is that Emacs would not provide a security
level that allows me to specify a trusted environment.  As someone who
may not understand all the intricacies of the individual security
features we provide, and might have no time to read up on all of them,
I might still be competent enough to set up my home network securely
(or hire someone to do that), and be sure it is not as vulnerable as a
public network or an Internet connection or the home network of the
guy next door.

> I donʼt think this is the right approach: the defaults should be as
> secure as we can make it whilst remaining reasonably convenient.

Once again, we agree with the principles, it's the details which
matter.  Isn't it true that any failed check will pop up some prompt
or message?  Isn't it true that each such prompt makes using Emacs
less convenient?  If the answer is YES to both questions, then we need
to find the optimal set of features we turn on so that Emacs is "as
secure as we can make it whilst remaining reasonably convenient".
Right?

> I see no real use case for 4 separate classes that could
> meaningfully be used by a typical user

How can you say that before we classify the risks into however many
classes they present?  Maybe I will agree with you once we have such a
classification, but not in advance.

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

I'm saying we cannot rely on the fact that NSM asks certain questions
only once.  We cannot see that feature as a solution for annoyance.

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

But people in physical danger need more protection, don't you agree?
And for those people in danger, additional inconvenience is justified,
right?  But that additional inconvenience is net necessarily justified
for people who are NOT in physical danger, for them it's just an
annoyance.  Same thing for when the probability of someone snooping on
you is lower than for someone else.

For these reasons, I find the "one level fits all" idea sub-optimal.

> As an aside, we should really try to steer people away from both
> cleartext *and* STARTTLS connections towards using direct TLS
> connections

I agree, but my point was that perhaps 'paranoid' should fail any
non-TLS connections, whereas other levels should not automatically
fail them.  Or something like that.

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

Yes, I think your perspective is different from mine.  I see quite a
few bugfixes that are important to get out ASAP.  Just look at "git
log" past the release, and I believe you will agree.

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

Thank you very much.