
Emacs and TLS - signa11
https://lwn.net/Articles/759370/
======
jancsika
> It isn't the Emacs way to second-guess our users' needs, definitely not to
> decide for them what is and what isn't a matter of life and death for them.
> We provide options with some reasonable defaults, and then let users make
> informed decisions which defaults are not good enough for them.

> It is IMO unreasonable to make our defaults match what happens in
> dictatorships that you describe, because that would unnecessarily
> inconvenience the majority of the users. Let's not follow the bad example of
> the TSA (whose rationale is, unsurprisingly, also matters of life and
> death).

Here's that same response in an alternate Gnuniverse where software
development is... different...:

"Thanks, Jimmy. Security is outside my wheelhouse, so let me run your ideas by
a security researcher I already know and trust. Then we'll figure out the most
effective way to improve TLS in Emacs without creating a maintenance burden
for the project.

Best, A sensible developer who knows what they don't know"

~~~
wyuenho
LOL, if only. It'll certainly save me a lot of work.

//edit BTW, those aren't my words, those are Eli's responding to Perry

~~~
jancsika
It is funny, but I didn't mean it as a joke.

It should generally be possible to predict the range of responses when
submitting a patch to a free software project, or when posting to a free
software list. If the input is "TLS" and the output is "TSA," it puts a strain
on _everyone_ and free software development suffers as a result.

------
mappu
Why is a tradeoff between convenience-and-security being considered? It's a
false dichotomy - Firefox and Chrome are secure-by-default and I do not find
them inconvenient at all.

Can emacs adopt their settings wholesale?

~~~
wyuenho
I agree. Many of the checks in my "netsec" branch does take inspirations from
Firefox and Chrome. However, there's a fundamental distinction - Emacs
currently has 4 security levels (hopefully soon reduced to 3), whereas
browsers only have one. There are also a few RFCs that demand terminating your
connection say when you've negotiated SSLv3. Emacs doesn't terminate and won't
terminate before asking the user first (with caveats). Another difference is
Emacs is used for all kinds of comms including email and Jabber, so browser
practices may present compatibility problems with protocols other than HTTP.
This is something that needs to be tested when my branch is merged into
master, but this is difficult, as the current strategy seems to be just wait
for a while and see if anybody complains. There's also a tendency for some
people to avoid the emacs mailing lists, so the signal, or lack there of, may
not be representative.

~~~
gsnedders
> There are also a few RFCs that demand terminating your connection say when
> you've negotiated SSLv3. Emacs doesn't terminate and won't terminate before
> asking the user first (with caveats).

That seems bad. There's plenty of evidence that if you ask the user "hey, do
you want to continue but be insecure?" they'll blindly click "yes".

While non-browser focused protocols may still rely on clients not forbidding
insecure protocols, we should absolutely be trying to move away from blindly
allowing insecure protocols (or effectively allowing them, given users
typically click "yes").

I'd _strongly_ suggest failing hard, and allowing per (host, port) exceptions
in the config file, rather than asking every time.

~~~
wyuenho
A number of people on emacs-devel, and IIRC, RMS too, suggests that we should
not be over-protective parents of Emacs users, and on most levels, I agree.
While this might seem like a strange philosophical position to take when it
comes to security, I don't think it is (or will be) the case for Emacs. An
Emacs user can override pretty much everything Emacs does, and there are well-
defined options where you can force a cipher suite or bypass NSM completely.
This might sound dangerous, but it's necessary in the event of a new TLS
attack was discovered, and that Emacs' default is vulnerable, the user can
easily override Emacs' and GnuTLS' default outside of both of these project's
release cycles. Given how infrequent Emacs releases, I think this is the right
approach.

~~~
ekidd
> _A number of people on emacs-devel, and IIRC, RMS too, suggests that we
> should not be over-protective parents of Emacs users, and on most levels, I
> agree. While this might seem like a strange philosophical position to take
> when it comes to security, I don 't think it is (or will be) the case for
> Emacs._

I've been a heavy Emacs user since 1997, using it as my primary editor on all
platforms. (In the last year or so, I've been mixing Emacs and Visual Studio
Code, because of the latter's solid support for particular language servers.)

I am completely horrified at the suggestion that it might be OK for Emacs to
have have insecure TLS defaults. This would be an absolute deal-breaker for me
(and would almost certainly result in Emacs being banned at work, with no
objection from me).

I do not have the time to fix every Emacs install on every server to be secure
with the latest TLS standards. I need to be able to trust the developers of
the software I use to get this right. I do not want to worry about whether
`package-install` has been affected by a MITM attack.

~~~
wyuenho
I love Emacs, but if I'm to be honest, if network security is of concern per a
company's policy, Emacs, any version of it past and present, should be
immediately banned.

------
move-on-by
> Pinning is what is done by sites like gmail to prevent third world
> dictatorships from using stolen certificate credentials to spy on their
> citizens. People who have been victims of this have had their email read,
> been arrested by state security forces for dissent, and have been tortured
> to death for lack of certificate pinning working in their browsers.

Well, this is awkward - Chrome has deprecated HPKP in favor of a new header:
'Expect-CT' [1]. The new header requires any cert to have a valid certificate
transparency log entry and has reporting features as well [2]. This is
slightly different - the scenario above would be allowed to happen and would
be be valid, but that it would be logged publicly. Whatever CA (dictatorships)
had issued the cert would lose their trusted status. But then again, if you
have a dictatorship, then you can require that your CA remains trusted and the
burden of removing trust to your dictatorship CA would be on individual users.

[1]: [https://www.zdnet.com/article/google-chrome-is-backing-
away-...](https://www.zdnet.com/article/google-chrome-is-backing-away-from-
public-key-pinning-and-heres-why/) [2]: [https://scotthelme.co.uk/a-new-
security-header-expect-ct/](https://scotthelme.co.uk/a-new-security-header-
expect-ct/)

~~~
Ajedi32
> if you have a dictatorship, you can require that your CA remains trusted

How?

I mean, I suppose you could mandate that all computers sold in your country
come preinstalled with state-approved monitoring software. But barring that,
what's going to stop users from downloading the latest version of Firefox
which includes code marking your CA as untrusted?

~~~
SSLy
A police baton

~~~
Ajedi32
Used against whom? The Firefox/Chrome/Microsoft/Linux developers don't live
under your dictatorship.

~~~
Fukkaudeku
The people who sell the computers in your country.

------
wyuenho
I'm the new guy mentioned in the article. This article is a bit late to the
party and misses a lot of details that I've discovered since June.

One of the reasons prompted this giant thread on the emacs-devel mailing list
is when I was updating my Emacs config to try out Gnus for email and
newsgroup, I discovered that no one seems to know exactly what a good TLS
Emacs config should look like and that Emacs comes with horrible defaults. In
addition, I was shocked that I've been exposed to a dozen TLS vulns that might
cause arbitrary code execution the whole time since package.el became a part
of Emacs back in circa-2013. After stuffing myself with about a dozen RFCs and
many dozen more papers and Chrome and Firefox blog posts, here's what I found
very concerning:

1\. The initial "a bit concerning" and "very concerning" qualifiers I
originally posted aren't as clear cut anymore, most of the 2 dozen failing
badssl tests are actually quite bad.

2\. NSM has got half a foot in the 2010s and half a foot in the 2000s. The
latest stable version of Emacs (26.1) only checks for SHA1 end-certificate,
usage of SSL, DH < 1024 bits and a noop RC4 cipher check (GnuTLS actually
calls it ARCFOUR).

3\. The half-done pinning mechanism does Trust on First Use while the user
can't even see the entire cert chain or the end cert.

4\. Only one fingerprint per host for TOFU, where Google low balances at least
between 2 end-certs AFAIK.

5\. Excessive and theatrical prompts for any URL that has not been visited on
a security level called 'paranoid.

6\. Multiple prompts for different problems found for the same TLS handshake.

7\. Setting one option in a configuration group called GnuTLS to true bypasses
NSM entirely. i.e. no cipher suite checks and happily accepts any 256-bit DH
key exchange attempts.

8\. No attempt to do any OCSP or Certificate Transparency revocation checking.

9\. 4 packages intermingled with each other all securing some network
connections badly with no documented relationships between them.

10\. Virtually no one who has commit access to the Emacs repo understands TLS.

11\. RMS prefixes every one of his email with:

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

while Emacs's network security settings is basically saying please come fuck
me.

The good news is, a few of these problems are already fixed on master and I've
pushed a branch called "netsec" to the Emacs repo last week that fixes most of
the rest. OCSP is coming this weekend. CT is going to wait quite a bit longer
as GnuTLS has no plan to support it anytime soon. I have hope to make at least
some of these security fixes to Emacs 26.2 or 26.3 in the short term. Medium
term plan is to lobby for requiring TLS for all email protocols because RFC
8314. The long plan is obviously support TLS 1.3 for Emacs 27, and possibly
HTTP2.

~~~
etu
Question: Wouldn't it just be easier for Emacs to link to libcurl which has
pretty much reasonable defaults (afaik, correct me if I'm wrong). The result
would be that Emacs wouldn't need to link to a specific TLS library or have to
maintain this. libcurl's API has a good reputation for not breaking :-)

Also big thanks for putting this work into Emacs. I use Emacs for hours at
least every work day and many non-workdays as well.

~~~
__david__
Emacs uses TLS for more than just HTTP. SMTP+STARTLS for instance…

~~~
oblio
You were saying: [https://stackoverflow.com/questions/14722556/using-curl-
to-s...](https://stackoverflow.com/questions/14722556/using-curl-to-send-
email)? :D

~~~
__david__
Fair enough, but does it do nntp, irc, pop, imap, jabber, etc? Emacs (for
better or worse) has a complete network API so people can implement all of
these things, and it doesn't want to be limited by a high-level library that
only supports some small subset (however large that subset is).

~~~
oblio
If you push hard enough...:
[https://curl.haxx.se/mail/lib-2012-02/0234.html](https://curl.haxx.se/mail/lib-2012-02/0234.html)
:)

------
waynecochran
I am missing something here. Emacs is a text/programmer's editor (I know you
browse the web, read email, talk to eliza, etc...), but where is TLS being
used exactly? (BTW, I have been using emacs since at least the early 90's, but
never did anything requiring TLS).

~~~
akalin
Do you ever install packages from Emacs? If so, you _definitely_ want that to
be at least TLS protected.

[https://glyph.twistedmatrix.com/2015/11/editor-
malware.html](https://glyph.twistedmatrix.com/2015/11/editor-malware.html) is
a post describing the problem and some solutions. I haven't checked to see how
many of the steps are still necessary on Emacs 26, but I bet it's still non-
zero.

~~~
simias
>Do you ever install packages from Emacs? If so, you definitely want that to
be at least TLS protected.

Wouldn't it make more sense to sign individual packages so that it doesn't
matter if an attacker can mess with them "in flight"? That's generally how
package managers work in my experience. It also means that you can let third
parties create mirrors without trusting them fully. TLS doesn't really seem
like the right solution for something like that.

~~~
tialaramex
This feels like enough, doesn't it? But it's not.

You will also need to sign and timestamp all repository metadata. Otherwise
when you learn of bug X and fix it with patch P to produce new package
package-V+1 I also learn of bug X, but I ensure my victims don't get told
about new package-V+1, they will be told package-V is the latest version and
they're now safely up-to-date - but I can exploit them.

If you use TLS I can't meddle with the packages, or the metadata, or anything.

You absolutely can secure everything in your package management system, but it
will be a bit trickier than just signing individual packages. Whereas using
TLS is enough.

Back in 1995 when anonymous FTP distribution was commonplace, signing packages
made a whole lot more sense than trying to get all your mirrors to update to
HTTPS. In 2018 this is not so true.

~~~
wahern
They should be doing all of that anyhow. Servers get hacked. TLS doesn't fix
the metadata replay problem.

------
pecg
I know that from a technical point of view, Emacs is not just a text editor; I
think it is a complete lisp virtual machine with a text-based interface that
happens to be prepared for editing text by default, and thus it should be
treated as such, instead of running it over as a userland program maybe one
day it works as a standalone operating system, with its own kernel and JIT
compiled lisp dialect. I'm saying this, because when I first started using
Unix-like operating systems Emacs was one of the things that attracted me the
most, but after actively using it for almost a year I saw how it moved away
from the expected operation mode of a typical Unix environment, and I didn't
like that. I came to appreciate the phylosophy of "One program to do one thing
and do it well... make programs that work together", I consider it an elegant
way to design and implement software, thus I don't see where Emacs fits on a
Unix-like system. In the end, I ditched it in favor of something much more
simple, fast and adecuate, this is where vis does an outstanding job, having
the unique plus of using a structural regular expressions engine, and
extensible using Lua. vis is small (source code and binary) and I don't have
to think about what SSL implementation it should use, because there is a
system library that does it for me, since vis is just a text editor, and
succeeds at it.

~~~
lispm
Emacs is a wide family of text editors. GNU Emacs is just one. Originally
Emacs was implemented as a set of TECO macros. The second Emacs was then EINE
(Eine is not Emacs). EINE was implemented in Lisp Machine Lisp on top of the
Lisp Machine OS. One of the next Emacs editors was Multics Emacs, an Emacs
implemented in Maclisp for the Multics mainframe computer. Both Maclisp and
Lisp Machine Lisp were full-featured Lisp implementations and thus their Emacs
was a Lisp-only implementation. From then on zillions of Emacs variants were
implemented. This provides a list of Emacs implementations:
[http://www.finseth.com/emacs.html](http://www.finseth.com/emacs.html)

GNU Emacs was developed as a text editor. Its implementation language are C
and Elisp - not only the VM is coded in C, but there are other parts written
in C. See for example: [https://github.com/emacs-
mirror/emacs/blob/master/src/frame....](https://github.com/emacs-
mirror/emacs/blob/master/src/frame.c)

Then Elisp is the extension language for writing extensions (like minor or
major modes) and applications using a text-editor user interface. These
applications are using the programmable editor buffer as their user interface
building block.

General enhanced Lisp implementations which run as a standalone operating
system, but which are not special purpose for editor implementation and which
are not providing an editor-based user interface exist(ed) several: MIT Lisp
Machine OS (and derived), Interlisp-D, ... Mezzano (
[https://github.com/froggey/Mezzano](https://github.com/froggey/Mezzano) ).

Since Elisp was an uncomplete and smaller Lisp - and not a systems programming
dialect like Lisp Machine Lisp - its code base is mostly like that: no lexical
binding, no real multithreading, no really scalable language constructs, ...
moving this language forward is a) not easy and b) not really in the core
interest (the core task is being a language for editor extensions).

Also it is questionable whether its editor user interface is a good model for
a general UI...

~~~
pecg
Thank you for this explanation, it gives me a better idea about Emacs' design.

------
vemv
Kinda on-topic, I still don't know how to setup Emacs 26 (which is a
relatively recent release) on macOS - as opposed to all prior versions.

Installation of packages will fail due to the TLS changes.

This seems the best-informed solution but it's not working for me:
[https://blog.vifortech.com/posts/emacs-tls-
fix/](https://blog.vifortech.com/posts/emacs-tls-fix/)

~~~
wyuenho
I don't know exactly why this solution won't work for you, there could be a
number of issues at play here.

In short, try this:

1\. Reset all your 'tls 'nsm and 'gnutls customize options to their defaults.

2\. $ rm -rf ~/.emacs.d/network-security.data

3\. Install [https://github.com/antifuchs/safe-tls-defaults-
mode/blob/mas...](https://github.com/antifuchs/safe-tls-defaults-
mode/blob/master/safe-tls-defaults.el)

This nice gentlement packaged up the settings I suggested on a Reddit thread.
It should work most of the time, if not, you can adjust the CLI string.

~~~
vemv
Tried out, no luck unfortunately. With that setup, both E25 and E26 get stuck
forever while trying to fill the `~/.emacs/d/elpa` directory (with an actual
freeze and no feedback)

~~~
wyuenho
What about emacs -q ? Does the same issue still happen? If it doesn't, that
sounds like a different package is locking up your emacs.

~~~
vemv
Finally identified the issue - I was adding Marmalade as a repo, which cert is
legitimately wrong (Chrome will warn over [https://marmalade-
repo.org/](https://marmalade-repo.org/)).

I just removed the repo - I'd say that Melpa won in recent years?

~~~
wyuenho
Oh it's won many years ago :)

------
dreamcompiler
I haven't been able to load a Melpa library with https for many months. I had
assumed it was just because MacOS is weird about TLS since it doesn't use
OpenSSL (getting freaking _curl_ to work for https in MacOS sometimes takes
hours of futzing around with libraries).

But maybe it's Emacs' fault?

