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

[Jimmy Yuen Ho Wong]

Whoa that's a lot of emails in one day! I understand that some of you
are concerned, I am too, that's why I raised this issue. Now, given
the volume, I don't want to respond individually, so please allow me
to summarize and address all of your concerns here.

First of all, having read all of your comments, I don't think anybody
is deliberately undermining Emacs' networks security. Emacs's network
security is the way it is mostly because of a lack of knowledge and
personnel. I don't think any of us is trying to hide that, and I think
we all want it to be better. Therefore, instead of arguing the issue
on moral ground, I propose we look at our common grounds and see what
we've already agreed on.

Before I dive deeper, here's a diff of my branch against master:

https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks

I'll refer to this in the rest of this long email.


You can have both freedom and security
-----------------------------------------------------
A lot of us take Emacs' infinitely malleability as granted, so we
don't even mention it, but that doesn't mean we don't care about
freedom or are trying to be paternalistic. In my branch, I have kept
the current NSM's structure - coarse grain security settings by
setting `network-security-level`, and find grain security by setting
`nsm-tls-checks`. This not only satisfies Eli's concern of providing
reasonable settings while preserving the freedom of users to decide
what's best for them, but also solves a more pertinent problem - the
necessity to adjust individual network security checks quickly in case
of a new kind of TLS attack outside of Emacs' release cycle. We can
either change Emacs's release process or keep NSM malleable, the
latter seems a quicker way out of this mess, and one which we can all
agree on.


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`
but can't for fear of being too naggy due to compatibility reasons.
RSA key exchange is still widely deployed, so is DHE due to it being
the only fallback for TLS 1.3. CBC mode is also widely a deployed
fallback cipher. All of the above are known to be insecure a lot of
times, but for me, **secure by default** means as secure *AND*
practical as possible by default, so until RSA KX, DHE KX and CBC
ciphers go away completely from the servers, I believe putting them on
the `high` level is appropriate.


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.


Less knobs can also mean more convenience and security
------------------------------------------------------------------------------
The `paranoid` level is security theatre. All it does is ask if you'd
like to connect to a server via TLS if you have never reached it
before. Why is attempting to securely connect to a server by using a
protocol that will authenticate it a cause for concern? Connecting to
a server via TLS does not mean the user start transmitting
confidential data immediately. That act  comes when you sign up or log
in. That's not TLS's job.

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 it not give the user a false sense of more security? Will
it mislead some innocent user to belive every host can be trusted
under `high` level? If the answer to the last 2 questions were yes, I
believe removing `paranoid` and its check is the right thing to do,
even if only for the sake of giving the right expectation.


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.

While I agree that blindly copying the security settings of the most
widely deployed TLS clients that we call browsers may not necessarily
be a good idea, it's also not a bad idea given Google and Mozilla's
army of InfoSec people looking after them. In addition, I haven't
copied them blindly. I have researched every single one of them by
reading about a dozen RFCs and papers in the past few weeks, and only
include them when applicable to Emacs' use of GnuTLS. See the
docstrings for details.


`gnutls-min-prime-bits` should be `nil` on Emacs 26.2
-----------------------------------------------------------------------
Setting `gnutls-min-prime-bits` to `nil` lets GnuTLS negotiate the
highest possible bit length based on its priority string, which means
at least 1008-bit since 3.3.0.

If my and other's positions on this issue have not been clear, let me
reiterate this - it was *never* appripriate to default
`gnutls-min-prime-bits` to 256. The list of reasons are the following:

1. If a user's email server demands 256 bits, it's not a sufficient
reason to sacriface the **secury by default** goal for the vast
majority of users by defaulting it to 256 just so everyone is on the
lowest common denominator possible.

2. US export regulation controls export of crypto components using DH
> 512 bit prime length to rogue states[2], that means NSA can break DH
with prime bits < 512, that also means possibly other state actors as
well. 256-bit default means **enabling mass-surveillance** for our
users world-wide.

3. If you are afraid of upping to > 1024 will interrupt many people's
workflow, don't. SSLLabs's Key Exchange Strength scan[3] shows there's
only 2.9% servers found using < 512 bit key exchange. 1024+2048+3076
bit servers cover ~ 95% of TLS server deployments out there. It makes
no sense to sacriface 95% for 2.9%. See 1).

4. Even if it regressed for some poor guy's connection to an email
server configured in the 80s, that's a **good** thing. If he ever
comes back to complaint about it, we can direct him to complaint to
the server admin instead, so we can all be safer. See 1) again.

5. Even if he turns out to have legitimate reasons to set prime bits
to 256 bits, it's not Emacs' problem. He just has to M-x
customize-set-value RET gnutls-min-prime-bits RET 256 RET.

There is absolutely no reason whatsoever to default
`gnutls-min-prime-bits` to 256, not even in the 90s.

[1]: https://ee.stanford.edu/~hellman/publications/28.pdf
[2]: 
https://www.bis.doc.gov/index.php/forms-documents/encryption/335-supplement-no-1-to-part-774-category-5-part-ii-information-security/file
[3]: https://www.ssllabs.com/ssl-pulse/


OpenSSL is nice, but getting much improved network security out the
door ASAP is nicer
----------------------------------------------------------------------------------------------------------------------
While OpenSSL certainly has its advantages, it is also a much bigger
target. When dealing with security issues, one has to consider the
economics. When economics are factored, an attacker will often ask if
it make sense to spend a month working on an attack to target a small
user base such as GnuTLS'. The answer to that is likely to be false.
But if we are on OpenSSL, any new attack targeted towards it will make
Emacs a target as well.

In addition, these days I try to live by a motto - Don't let the
perfect be the enemy of the good. Replacing GnuTLS with OpenSSL is
significantly harder than writing a couple C functions to get the most
out of GnuTLS. Replacing it without major regressions even harder.
Besides, most of Emacs' network security problems do not come from it
use of GnuTLS, but deficiencies in NSM. I believe Emacs' network
security can get much better faster if we focus our efforts on the
current design.


Documenting security changes
-----------------------------------------
Currently, Emacs' network security settings are poorly documented and
widely misunderstood. There's only one page on the entire Emacs manual
that briefly describes the checks NSM has, but it doesn't mention what
its relation is with GnuTLS. There is also no mention of NSM or GnuTLS
in the Emacs Lisp Reference whatsoever. 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*)


Jimmy


On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman <address@hidden> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I don't know what this issue concretely involves, so I don't have
> an opinion about what concretely we should do.  But I'd like to suggest
> a possible avenue for choosing a good response.
>
> The idea is that we make sure users see a chance to choose between the
> alternatives (convenience and safety) early enough that they won't be
> unsafe.  The choice should come with an explanation of each option,
> first stating what situations it is recommended for, then what it does.
>
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>

On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman <address@hidden> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > So far as I can tell and am aware, OpenSSL is fully free software.
>   > There are no unfree components.
>
> OpenSSL had, in the past, a license incompatible with the GNU GPL.
> If its license is unchanged, using it with Emacs would require some
> inconvenient work to install a license exception.
>
> That is assuming there is no non-FSF-copyrighted GPL-covered code
> linked into Emacs.  If there is some, that is not inconvenient but
> impossible.
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>