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

[Jimmy Yuen Ho Wong]

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

Been waiting for you to say that :)

In 
https://github.com/wyuenho/emacs/commit/35d720eceef5c9b1dc0553b7d2235bbb079b0036
, I've used Snowden as an epoch, and separated the checks known to be
necessary before Snowden, the response post-Snowden, and preparations
standard bodies and browser vendors do to prepare for TLS 1.3. The
count is now 10 lows, 13 mediums (10 low + 3), and 17 highs (13
mediums + 4).

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

Alright... I cave. I see what you want now, you want an escape hatch
for implicitly trusted network hosts. I'll make you a deal, if you can
give me cross-platform C DEFUNs of getifaddr(3), getaddrinfo(3) and
getnameinfo(3), I'll give you a `nsm-trust-local-network` boolean. If
`nsm-trust-local-network` is non-nil, or a function that returns
non-nil when `nsm-trust-local-network` is read, connecting to such
hosts via TLS will be whitelisted automatically in memory. The
docstring should say use this at your own risk. This should smooth out
your home network situations, and like-wise for corporate intranets.

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

You only land on the `network-stream-open-starttls` code path when you
request :type 'starttls, I think this makes sense. This also is the
approach recommended by RFC 2595, 3207 and 7425. The only protocols in
Emacs that request STARTTLS, AFAIK, is IMAP, SMTP, POP3 and NNIP. I'm
not sure if there are defcustoms in these packages that decides
whether to terminate the connection if STARTTLS is not possible.
Regardless, RFC 8314, fresh out of the oven in Jan this year demands
Email related protocols to require TLS implicitly. STARTTLS will soon
be obsolete anyway.

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

Most of the CAPITAL LETTER cute name vulns you can Google are targeted
towards TLS, but demostrated with HTTP, but that doesn't mean their
effects only are only limited to HTTPS. They are simply demostrated
with HTTP so people can get a better sense of their severity as it's
the most well-known protocol out there. The only instance of a cross
protocol attack that only targets a specific application protocol that
I'm aware of is an instance of CRIME called BREACH, of which there's
no known effective countermeasure.

There are however, plenty of implementation-specific vulns that do not
apply to Emacs and GnuTLS. You may have heard of them. (*cough*
Heartbleed *cough* gotofail *cough*)

None of the checks I've thrown in are mitigations for OpenSSL
implementation faults of targeted towards specific application
protocols. They apply to ALL TLS connections.

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

I said you *might be*, and that's what the warning is about. Emacs
can't decide for the user under such circumstances. No one ever said
anything about assuming everyone is always under attack, we are saying
user are exposed to these attacks, if you don't have these checks.
These attacks may or may not be happening when you connect to a
server, but you can certainly detect them or prevent them by using a
combination of automated checks and human intervention.

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

But it is only about TLS. Do you really want Emacs to prompt you when
you are browsing http://www.some-random-guy.com/blog ? Browsers can do
with a green padlock, the best Emacs can do is bleep out a message in
the echo area or put a Unicode padlock in the mode line. But this is
too application specific, it's best done in EWW or whatever.

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

They use Github's RESTful API to login, and clone the repo with
`shell-command`. You can file issues and submit PRs on Github using
Emacs too.

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

Oh ye faithful disciple of the religion of Murphy's Law, may your hair
show youthful color again by changing Emacs' release process to a
Continuous Integration and Delivery process.