Emacs and TLS
lwn.net
lwn.net
> 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"
//edit BTW, those aren't my words, those are Eli's responding to Perry
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.
This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing.
Now that I've had the relevant comment out of the way, let me be a little more general.
> It isn't the Emacs way to second-guess our users' needs
This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet.
It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem.
However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there.
I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion.
So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.
Can emacs adopt their settings wholesale?
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.
We all agree that Emacs should provide sensible defaults, the disagreement is what that sensible defaults consist of.
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.
I really do.
So to interact with those systems via HTML I have do lots of “yes I know it’s insecure, I’m trying to fix that, let me past.” As the barrier is getting higher, sometimes I simply can’t get past.
This is a pain.
Emacs, let’s be kind, doesn’t have a consumer audience. It has an audience working on immature/developing/broken systems.
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-... [2]: https://scotthelme.co.uk/a-new-security-header-expect-ct/
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?
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. ]]]
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.
Beyond that, npm is far more vulnerable. But it rarely matters. The reason is culture and community.
To bring this back to the topic at hand: npm as an ecosystem is far more vulnerable than the points you mention. It's worth considering why people do not routinely pwn those who use npm. The fact that you are vulnerable does not mean it's a good idea to try to throw an entire ecosystem under the bus.
The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now.
It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does not mean that (a) anyone has exploited them or (b) that you are in any kind of danger.
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.
This sentence makes it sound like anyone who has used emacs in any way since 2013 has been in immediate risk of having their computer taken over. Maybe that's true. But even if it were true, what precisely would the steps be to make this attack happen? Have you proved that it can be done?
EDIT: The main point I'd like to get across is that it's worth fixing security problems, but it's important to maintain a spirit of cooperation rather than accusation. Everyone has security issues. Even (perhaps especially) the big names that you wouldn't expect to. That's why people pay pentesters a lot of money -- we're effective at making sure no one else finds them before we do. But emacs doesn't have the resources to get a pentest, and out of all the security vulnerabilities they could possibly have, a few TLS flaws wouldn't even be marked as medium severity unless there were a direct way to take over a user's computer via the flaw.
Back to topic:
While I agree that being vulnerable is not the same as being attacked, I still have a hard time understanding why you seem to be downplaying the significance.
First of all, I don't have to prove anything, all the papers that describe actual explotable TLS vulns over HTTP and SMTP/IMAP equally applies to Emacs if you've ever downloaded something over HTTPS or login to a server say Github via an API package like ghub.el. Email is worse with STARTTLS, although the attributes are different. SMTP/IMAP connections tend to be much shorter and less frequent, so your area of exposure may be smaller> But since emails tend to contain a lot of vital PII, the actual harm is probably greater than knowing your session cookie for a blog. Losing email credentials is also quite devastating.
Second of all, TLS is mostly used to guard against all kinds of MITM attacks. There are some kinds of MITM attacks easier to carry out than others, and they don't have to be targeted. Logging into your email account using a coffee shop's wifi without checking for known vulns before tranmission of TLS records doesn't sound very comforting to me.
Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
P.S Since we are putting out credentials, I used to work at Cloudflare, not that I was in any security or systems engineering capacity, but I have also been quite interested in security issues. I guess that makes me a "security-hobbyist".
//edit after your edit
You probably should stop accusing me of accusing anybody, that's the exact opposite of what I have done. Please read the last link in the article (https://lwn.net/Articles/759460/).
Yes, you do. That's pentesting 101.
Think of it this way. Would it be reasonable for pentesters to say "You're critically vulnerable. But I haven't verified this"?
More times than I can count, when I went back to verify whether I was correct, I wasn't. For subtle reasons. If you haven't put in the work, you don't know whether you are right.
Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
You have never worked in security. The fact that you're shocked at this shows how green you are. I don't mean that in a dismissive or insulting way, but if you'd just go do a stint as a pentester for a year, or talk to some pentesters in the field, you'll quickly stop being shocked at this.
You have a responsibility as someone who is presenting security issues to know what you're talking about. Most people listen to whoever talks the most confidently. And the bare minimum work is proving that the exploits you're presenting are actually applicable to the situation at hand.
Most people don't know security, and very few people will check your work to ensure it's correct. That means when some hobbyist steps up and starts yelling about theoretical issues, it's important to step in and say "Actually, these issues haven't been demonstrated."
What if it takes $100M to MITM someone? Would you say it's still worth being shocked that you're theoretically vulnerable to this? What is the precise cost of someone who actually wanted to MITM someone else using emacs? Have you done the math?
This isn't me downplaying the significance. This is me saying "Do the work." And if you haven't, then you should classify the vulns as low severity. That's what we did whenever we didn't know for a fact that you could own someone's app/box.
> You have never worked in security. The fact that you're shocked at this shows how green you are. I don't mean that in a dismissive or insulting way, but if you'd just go do a stint as a pentester for a year, or talk to some pentesters in the field, you'll quickly stop being shocked at this.
Does the fact that you are numbed to snafus like this justify the terrible state of network security of a continuously maintained 30+ year old editor? I expected more from the countless number of Emacs hackers came before me.
I urge to you go thru the mailing list thread, but if you don't want to, I understand as it's rather long, but please don't assume you know what I've done or haven't done or how much I understand these issues, or my intentions. We've never met, never conversed before, you don't know anything about me.
I don't see where you got any of that. I read point #11 as citing RMS in his capacity as an authority on GNU goals and principles, a capacity in which he still contributes guidance to Emacs and other GNU projects.
Maybe there's some context missing. GNU is an unapologetically political project; decisions are meant to be made not solely in pursuit of some narrow definition of technical superiority or correctness, but being mindful of their effects on the free software movement and human societies in general. From that perspective, it's completely reasonable to be surprised if a GNU project appears to be out of alignment with a major sociopolitical concern of RMS. For example, if GCC 9.0 were released under the original BSD license, people would be surprised and concerned for fundamentally similar reasons.
In the context of TLS in Emacs, I don't see how it is a very concerning point in similar style as failing badssl tests. The implied claim that RMS is writing his footer because he thinks the emacs security is faulty is not supported. As such the RMS part of #11 is not supported and do not contribute to the TLS implementation and configuration discussion in regards to Emacs.
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.
And on their page they have a zillion protocols: https://curl.haxx.se/
Maybe it would be worth trying out.
As the Fedora bug notes, Default TLS security policies for the Web PKI belong at the OS level, where they can be set by a small number of people who are really thinking about these problems, once. Microsoft has done this (not very well, but they've done it) in modern SChannel .NET support, it is finally relatively easy to write code which says "I don't know, please have the usual amount of security" rather than "I'm an expert, enable this protocol version, these exact ciphersuites, and use this key" or as it more commonly the case "Here's something I pasted from a 2010 Stack Overflow post". As much as possible, and despite all insistence to the contrary by individual developers, these preferences shouldn't live in some effectively unmaintained code in each individual component.
1. In particular if you don't actually care about the identity claimed in the certificate, you shouldn't bother verifying anything at all since obviously bad guys can trivially obtain a cert for some identity.
This was once a VERY common problem, and it's still seen in plenty of places (e.g. one of the toy operating systems doesn't check at all, so the whole OS is wide open, package updates, web browser, the whole thing - another has told users any time there's a problem to switch verification off manually, so I would expect few have it left switched on by now)
2a. Although it feels as though turning min-prime bits up to 2048 would fix things, in practice interoperability is very poor. You might get away with this, in some cases, for say IMAP and SMTP submission with TLS, but it's unlikely to be satisfactory on the general web. Try asking for Elliptic Curves instead.
2b. Everybody called it ARCFOUR (Alleged RC4) for legal reasons, it's fine, don't worry about _that_.
3. I sympathise here, in principle the user ought to have examined the cert, or at least key, they're trusting. But realistically users don't do this, so the security penalty is very small indeed. Examining the entire chain is largely futile, a lot more work and an even smaller number of users would gain anything from it.
8. There isn't really such a thing as "Certificate Transparency revocation checking" and revocation is largely a dead letter for big public CAs in the Web PKI. Almost certainly a bad guy able to attack you using a real cert isn't going to be prevented in their attack by revocation, they will block the signal and you'll fail open, because as we saw in every other item, users switch off any annoying fail-closed machinery.
10. This isn't great, but the idea behind SSL/TLS is that this ends up just being a drop-in replacement for the socket layer. With the exception of some scary features like TLS 1.3's Zero RTT no TLS expertise is needed, and the correct approach if you have no TLS expertise in the Emacs developer team is to just never use those scary features, they're supposed to be gated so that you can't use them by accident.
Emacs's use of GnuTLS already delegates something to the OS, namely getting the system's root CA certs. As for the rest, I lobbied leaving GnuTLS defaults alone instead of intentionally lowering it to accept 256 bit DHE primes only to be warned by NSM later. Also, the default cipher suite other than DHE prime bits is already left alone OTTB.
But.... Emacs being all about freedom and infinitely hackable, the philosophy (philosophers?) demand that we let users to be able to configure the lower bound of acceptable TLS security in 2 different places, because someone somewhere requested it at one time, therefore his or her need trumps everyone else's default security or requests to have a consistent UI for TLS configuration. This is the context behind that fixation quote Lars wrote. Of course, I disagree strongly. The good news is, I've already returned all GnuTLS knobs to their defaults in my branch, and Lars has fixed the docs so people know they probably shouldn't touch those GnuTLS settings unless they want to bypass NSM completely, say running a elisp script for example.
I'm not going to respond to the rest of your points, they require a fair bit of context to understand why I think they are problems. I'll probably explain it in a blog some time this weekend.
Could you say which OSes?
The Emacs internal managers all go towards the same HTTP(S) sources and I haven't seen one that pins input hashes or uses signatures, with the exception of pinning git commit hashes when using git as a package source in straight.el[2].
[1]: https://github.com/tazjin/nixos-config/blob/master/emacs.nix [2]: https://github.com/raxod502/straight.el#advantages-of-straig...
Emacs is a superior environment for anything having to do primarily with text. Mail is mostly text, so it's a natural fit. Most of the actually useful content on the Web is text as well, so a large percentage of browsing can benefit from this environment as well.
I use Calfw[1] to keep an eye on my calendar, I believe this mode uses TLS when communicating with Google, etc.
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.
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.
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.
See if this works for you on Emacs 25 and 26: https://news.ycombinator.com/item?id=17573969
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....
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 ).
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...
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/
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...
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.
I just removed the repo - I'd say that Melpa won in recent years?
But maybe it's Emacs' fault?