7 ms·

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 reaso

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.

tialaramex 8y ago
Briefly (?): 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.

tialaramex 8y ago

Briefly (?): 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.