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…
Question: Wouldn't it just be easier for Emacs to link to libcurl which has pretty much reasonable defaults (afaik, correct me if I'm wrong). The result would be that Emacs wouldn't need to link to a specific TLS library or have to maintain this. libcurl's API has a good reputation for not breaking :-) Also big thanks for putting this work into Emacs. I use Emacs for hours at least every work day and many non-workday…
Emacs and TLS
31–40 of 83 posts
Re: Emacs and TLS
#32I'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…
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.
Re: Emacs and TLS
#33I am missing something here. Emacs is a text/programmer's editor (I know you browse the web, read email, talk to eliza, etc...), but where is TLS being used exactly? (BTW, I have been using emacs since at least the early 90's, but never did anything requiring TLS).
You answered it yourself: When you browse the web and read email.
Re: Emacs and TLS
#34Earlier quoted context omitted.
You answered it yourself: When you browse the web and read email.
Yes, but who actually does that?
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.
Re: Emacs and TLS
#35I am missing something here. Emacs is a text/programmer's editor (I know you browse the web, read email, talk to eliza, etc...), but where is TLS being used exactly? (BTW, I have been using emacs since at least the early 90's, but never did anything requiring TLS).
Do you ever install packages from Emacs? If so, you definitely want that to be at least TLS protected. 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.
Re: Emacs and TLS
#36Why 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?
I really do.
Re: Emacs and TLS
#37Why 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?
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…
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.
Re: Emacs and TLS
#38Installation 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/
Re: Emacs and TLS
#39Earlier quoted context omitted.
Question: Wouldn't it just be easier for Emacs to link to libcurl which has pretty much reasonable defaults (afaik, correct me if I'm wrong). The result would be that Emacs wouldn't need to link to a specific TLS library or have to maintain this. libcurl's API has a good reputation for not breaking :-) Also big thanks for putting this work into Emacs. I use Emacs for hours at least every work day and many non-workday…
Emacs uses TLS for more than just HTTP. SMTP+STARTLS for instance…
Re: Emacs and TLS
#40Earlier quoted context omitted.
Question: Wouldn't it just be easier for Emacs to link to libcurl which has pretty much reasonable defaults (afaik, correct me if I'm wrong). The result would be that Emacs wouldn't need to link to a specific TLS library or have to maintain this. libcurl's API has a good reputation for not breaking :-) Also big thanks for putting this work into Emacs. I use Emacs for hours at least every work day and many non-workday…
As far as I know you can't use libcurl to talk to smtp, or other protocols like that. They need generic socket support.
And on their page they have a zillion protocols: https://curl.haxx.se/
Maybe it would be worth trying out.