Emacs & TLS

A recent query about the status of network security (TLS settings in particular) in Emacs led to a long thread in the emacs-devel mailing list. That thread touched on a number of different areas, including using OpenSSL (or other TLS libraries) rather than GnuTLS, what kinds of problems should lead to complaints out of the box, what settings should be the default, and when those settings could change for Emacs so as not to discombobulate users. The latter issue is one that lots of projects struggle with: what kinds of changes are appropriate for a bug-fix release versus a feature release. For Emacs, its lengthy development cycle, coupled with the perceived urgency of security changes, makes that question even more difficult.

Questions and concerns

In mid-June, Jimmy Yuen Ho Wong posted some "questions and concerns about Emacs network security" to the list. He had run some tests making TLS connections to web sites with bad certificates, but found that Emacs did not complain about the problems. The default values for some security settings were inadequate, he said; he proposed a set of better defaults, but there were still some failures. So he wondered:

The emacs-devel post came out of a much less temperate reddit post. In it, he noted that tls.el and starttls.el have been deprecated on the master branch. Using those, he could build Emacs without GnuTLS and use the OpenSSL command-line programs for his TLS connections, but that option is going away. In his mailing list post, he also asked about nsm.el, which is the Emacs Network Security Manager: It is "seemingly doing redundant checks if your TLS settings are reasonable, what's the history of it and why is it not obsolete when `tls.el` and `starttls.el` are?"

The settings that Wong complained about (gnutls-verify-error, gnutls-min-prime-bits, and gnutls-algorithm-priority) are actually for the lower-level gnutls.el library that is the interface to GnuTLS, Lars Ingebrigtsen explained. "The Emacs Network Security Manager does the user interface job handling various classes of (insecure) network access classes", he said. He is the developer of NSM and wrote a blog post about it when it was merged back in 2014. NSM was released as part of Emacs 25.1 in 2016. In a subsequent emacs-devel post, he clarified the role of NSM:

But there are still more problems that Wong has found. He listed around two dozen badssl.com sites that did not give any errors when he accessed them from Emacs using the default settings. Three of the failures he rated as "very concerning" (revoked., pinning-test., and sha1-intermediate.) and another was "a bit concerning" (invalid-expected-sct.). All of those were run with the default value of network-security-level, which is "medium"; setting it to "high" only resulted in complaints from two of the sites with too small Diffie-Hellman key sizes (dh480. and dh512.).

Ingebrigtsen acknowledged some of those problems; he suggested that more of those sites should result in complaints on the high security level and that the Diffie-Hellman complaints should move from high to medium. He seemed less convinced on the certificate-pinning problem, but was interested in patches to implement the complaint for a revoked certificate. He also filed a bug to remind himself of a feature he has planned to make the protocol checks more extensible.

Security tradeoffs

Certificate pinning—really public-key pinning—is important, Perry E. Metzger said. In contrast to Ingebrigtsen's ambivalence, Metzger said that it can be a "matter of life or death for many people". Sites can request that their public keys be stored by the browser using HTTP Public Key Pinning (HPKP), not doing so could be disastrous:

But Emacs co-maintainer Eli Zaretskii is concerned that adopting such measures will result in extra prompts and other inconveniences for those who are not living under such conditions:

The settings of various web browsers were often discussed in the thread, at least as a starting point for what the Emacs defaults should be. But NSM is used for more than just web browsing (IMAP, for example) in Emacs, so the fit is not exact. The Emacs Web Wowser (EWW) is used to browse the web, though, so Emacs can learn from the other browsers. As Paul Eggert put it:

But Zaretskii thinks there is more to it since Emacs does more with TLS than just web browsing:

Richard Stallman weighed in as well; he disclaimed knowledge of the details, but suggested a "possible avenue for choosing a good response". He wants to ensure that, early on, users get a way to at least consider the question: "might thugs with torture chambers be spying on me" (as he put it in another message).

No one really disagreed with that idea, but it is also not really the focus of ongoing efforts. The idea seems reasonable, but the implementation—wording in particular—may be harder than it sounds.

Prime bits

The current setting in Emacs for the minimum number of bits in the prime number used as part of the Diffie-Hellman key exchange algorithm is 256, which is woefully small, according to Wong and others. Various kinds of attacks on key exchanges with small primes are known and TLS-downgrade attacks can be used to force the key exchange to use these smaller prime numbers. Currently, browsers set their minimum to 1024 bits, which is still thought to be susceptible to state-level attackers. Given that, Noam Postavsky asked if that default could be bumped to 1024 on the release branch.

Zaretskii was opposed to doing so on the release branch, since the amount of testing it would require would likely delay the Emacs 26.2 bug-fix release. Part of the changes that Ingebrigtsen has planned would change the medium security level so that NSM would complain about small primes, but it is not clear that those changes would make it into 26.2. Zaretskii is concerned about "unintended breakage" from this kind of change, but others, including Postavsky think "it's unfortunate that we're still going to release a 26.2 which silently accepts primes smaller than 1024 bits by default".

It turns out, however, that NSM does complain about primes that are smaller than 1024 bits, according to Ingebrigtsen. That is a bit inconsistent with the gnutls.el setting, but it does at least solve the problem. Users who have a need to connect to servers with 256-bit Diffie-Hellman primes can still do so without changing gnutls-min-prime-bits, albeit with a warning. Wong got a bit heated in his response, though Ingebrigtsen thought it all makes sense: the lower layer can still do things that the upper layer will warn the user about. He also pointed out that Wong may not be looking at the big picture:

Along the way, Wong also posted his plans for handling some of the areas where NSM is not up to date with the latest TLS best practices. That includes support for Certificate Transparency (CT), which is being deployed by some browsers instead of HPKP, better support for HPKP, better cipher suite and TLS extension checks, and so on. While Ingebrigtsen has quibbles and has not actually looked at the code, he thinks Wong "is very much on the right track". It would seem that before long Emacs will have a better network security story—though it may not get out to users until Emacs 27, whenever that might be.

Switching TLS libraries

The suggestion to switch to OpenSSL is popular with some, but there are some barriers as well. One, which likely will occur to anyone who has been keeping an eye on OpenSSL over the years, is licensing. OpenSSL has its own unique license that is not compatible with the GPL; other projects have run into that incompatibility along the way. But OpenSSL has been actively working to relicense itself under the Apache Software License v2. As of March 1, the project is close to being able to switch; it plans to do so with its next release.

Another potential issue is the "Gnu" in GnuTLS, but that is something of an accident of history. GnuTLS moved out of the GNU project back in 2012. Normally, GNU projects (such as Emacs) are strongly encouraged (or more) to support and use other GNU projects, but that is no longer a consideration here. However, Zaretskii noted that Emacs had "just switched to GnuTLS as the primary means in Emacs 26.1" and that maintaining both a GnuTLS and an OpenSSL version of the TLS code would be a maintenance burden. He was firmly opposed to the idea.

In the end, Wong more or less agreed. In a lengthy message, which covered a lot of other topics, he said:

It was a long and scattered thread, but the end result looks like a nice improvement in Emacs network security that comes from a new Emacs developer—Wong went through the process of assigning copyright to the FSF in one of the sub-threads. There are a lot of "fiddly bits" when it comes to network protocols, especially those involving encryption, key exchange, and so on. Having a new expert interested in working on those problems will be a boon to Emacs and its users.