|Did you know...?|
LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.
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:
- Can we update the default network security settings?
- Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't seem to be doing a very good job, can we link to something better maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?
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:
Network security management is done by nsm.el, not by the underlying libraries. The NSM provides, as the name implies, network security, and does stuff like certificate pinning and warns you if a STARTTLS connection has degraded to a non-TLS connection (which, of course, the gnutls.el functions can't do on its own).
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.
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:
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.
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:
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).
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:
However, when Emacs is used to browse the web there's a powerful argument to model its security practices on those of other web browsers. A lot of practical experience has gone into the Firefox and Chrome security models, and it would be much, much more efficient for us Emacs developers to reuse those wheels instead of reinventing them.
But Zaretskii thinks there is more to it since Emacs does more with TLS than just web browsing:
NSM is used for every net connection, not just those on behalf of EWW. If you are arguing that NSM should apply different settings to EWW connections and to the other kind, then this is a separate issue.
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).
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.
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.
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:
Both here and in other places in this thread you seem to fixate on the particular use cases you're interested in to the extent that you say that other use cases are wrong, somehow. People have different needs and different approaches, and Emacs should empower them to get their work done, and not pressure them into doing it the way we think they should do it.
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:
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 [its] 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.
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.(Log in to post comments)