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?
Emacs and TLS
21–30 of 83 posts
Re: Emacs and TLS
#22Earlier quoted context omitted.
The old joke goes, Emacs is a great OS, if only it had a decent text editor!
You beat me to the punchline. Yes, you can do pretty much anything. (Edit: I guess in the spirit of the joke anything besides writing lol. Shameless plug: I use emacs.)
How about booting straight into emacs? https://www.informatimago.com/linux/emacs-on-user-mode-linux...
Re: Emacs and TLS
#23I'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
Re: Emacs and TLS
#24Why 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 (with caveats). Another difference is Emacs is used for all kinds of comms including email and Jabber, so browser practices may present compatibility problems with protocols other than HTTP. This is something that needs to be tested when my branch is merged into master, but this is difficult, as the current strategy seems to be just wait for a while and see if anybody complains. There's also a tendency for some people to avoid the emacs mailing lists, so the signal, or lack there of, may not be representative.
Re: Emacs and TLS
#25Earlier quoted context omitted.
I'm a former pentester. I used to do this kind of work for a living. Secondly, the Snowden leaks were one of the most important events in modern history, and you're on here using them as a cheap way to push your own agenda. Thirdly, RMS hasn't been an active emacs developer for quite awhile, but you're still trying to criticize him. To bring this back to the topic at hand: npm as an ecosystem is far more vulnerable t…
What's my agenda exactly and why do you think I'm criticizing RMS? Is that quote my words? And what does being a former pentester have to do with anything you said? Which ecosystem am I throwing under the bus?
The quality of HN is more important than winning. Let's have a conversation worth reading.
The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now.
It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does not mean that (a) anyone has exploited them or (b) that you are in any kind of danger.
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.
This sentence makes it sound like anyone who has used emacs in any way since 2013 has been in immediate risk of having their computer taken over. Maybe that's true. But even if it were true, what precisely would the steps be to make this attack happen? Have you proved that it can be done?
EDIT: The main point I'd like to get across is that it's worth fixing security problems, but it's important to maintain a spirit of cooperation rather than accusation. Everyone has security issues. Even (perhaps especially) the big names that you wouldn't expect to. That's why people pay pentesters a lot of money -- we're effective at making sure no one else finds them before we do. But emacs doesn't have the resources to get a pentest, and out of all the security vulnerabilities they could possibly have, a few TLS flaws wouldn't even be marked as medium severity unless there were a direct way to take over a user's computer via the flaw.
Re: Emacs and TLS
#26I'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-workdays as well.
Re: Emacs and TLS
#27Earlier quoted context omitted.
What's my agenda exactly and why do you think I'm criticizing RMS? Is that quote my words? And what does being a former pentester have to do with anything you said? Which ecosystem am I throwing under the bus?
The quality of HN is more important than winning. Let's have a conversation worth reading. The reason I laid out some creds is because you seemed to ignore the substantive part of my comment, twice now. It is tradition in the security field to make every security incident seem like a very big deal. (See tptacek's comment on cloudflare's memory leak, for example.) But just because there exist vulnerabilities, it does…
I'm not trying to win anything, I'm trying to find out where that dismissive tone came from, and see if there's any merit.
Back to topic:
While I agree that being vulnerable is not the same as being attacked, I still have a hard time understanding why you seem to be downplaying the significance.
First of all, I don't have to prove anything, all the papers that describe actual explotable TLS vulns over HTTP and SMTP/IMAP equally applies to Emacs if you've ever downloaded something over HTTPS or login to a server say Github via an API package like ghub.el. Email is worse with STARTTLS, although the attributes are different. SMTP/IMAP connections tend to be much shorter and less frequent, so your area of exposure may be smaller> But since emails tend to contain a lot of vital PII, the actual harm is probably greater than knowing your session cookie for a blog. Losing email credentials is also quite devastating.
Second of all, TLS is mostly used to guard against all kinds of MITM attacks. There are some kinds of MITM attacks easier to carry out than others, and they don't have to be targeted. Logging into your email account using a coffee shop's wifi without checking for known vulns before tranmission of TLS records doesn't sound very comforting to me.
Security, most of the time is about prevention rather than mitigation after the fact, just like you would wear a seat belt even though your likelihood of dying in a car crash isn't very high. Am I supposed to be not shocked to discover my car comes with a seat belt made out of a thin piece of printer paper?
P.S Since we are putting out credentials, I used to work at Cloudflare, not that I was in any security or systems engineering capacity, but I have also been quite interested in security issues. I guess that makes me a "security-hobbyist".
//edit after your edit
You probably should stop accusing me of accusing anybody, that's the exact opposite of what I have done. Please read the last link in the article (https://lwn.net/Articles/759460/).
Re: Emacs and TLS
#28I'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" 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.
Re: Emacs and TLS
#29I'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…
I thought about linking in curl, but curl doesn't seem to offer any help in making OCSP requests separately, it only has support for OCSP stapling. Not that not having OCSP by itself is a major issue, but not having OCSP, CT and a reliable and complete CRL set to check for certificate revocations is. Since GnuTLS is a readily available, and has APIs that make OCSP requests and verify OCSP responses, and Emacs itself can already open network sockets, in the end I've decided to stick to a bunch of Lisp and a couple of simple C functions for GnuTLS.
Re: Emacs and TLS
#30I'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 uses TLS for more than just HTTP. SMTP+STARTLS for instance…