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…
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" rath…
> 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
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/
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.
Your point #11 is a bit distasteful. Beyond that, npm is far more vulnerable. But it rarely matters. The reason is culture and community.
I appreciate you announcing your preference of taste, but honestly, if you don't have anything of substance to add to the conversation, please don't pollute the thread.
The RMS quote should be seen in the light of the usual message when security researcher talk about the NSA. That is to say if you need protection against state level attackers, relying on a single layer of security technology is insufficient and should always be considered as an exploitable vulnerability that will be broken at some time in the future. Imploring the state actors to act in the same moral way as Snowden is here a last line of defense.
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.
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 (wi…
> 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 insecur…
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.
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…
Thanks for your efforts, really appreciate it. I use Emacs daily so it's critical for me that it's secure
Don't thank me yet, a lot of these haven't made into master, thank me later if my lobbying effort is successful. :)
I appreciate you announcing your preference of taste, but honestly, if you don't have anything of substance to add to the conversation, please don't pollute the thread.
The RMS quote should be seen in the light of the usual message when security researcher talk about the NSA. That is to say if you need protection against state level attackers, relying on a single layer of security technology is insufficient and should always be considered as an exploitable vulnerability that will be broken at some time in the future. Imploring the state actors to act in the same moral way as Snowden…
I agree with your first paragraph, but I didn't claim RMS thinks Emacs security is faulty. In fact, RMS doesn't seem to be aware of the problems of Emacs' network security. That RMS quote is there to point out the irony that RMS cares enough about security and privacy to prefix all of his emails with that preamble, but not enough to alarm emacs-devs about it. It's well-known that RMS has not been active in Emacs' development for many years now, the responsibility is not on him anymore.
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?
> Firefox and Chrome are secure-by-default and I do not find them inconvenient at all. I really do.
> 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 insecur…
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…
I'm struggling to see the philosophical problem with being as secure as possible by default (aka "over protective") and letting the user configure overrides as necessary?
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/
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... This nice gentlement packaged up the settings I suggested on a Reddit thread. It should work mos…
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)
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…
I'm struggling to see the philosophical problem with being as secure as possible by default (aka "over protective") and letting the user configure overrides as necessary?
There isn't. I've said this a couple of times in the mailing list. It's just some people appear to think there is, but I don't believe them.
We all agree that Emacs should provide sensible defaults, the disagreement is what that sensible defaults consist of.