Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs and TLS

lwn.net

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Emacs and TLS

#61

Post by SSLy »

Ajedi32 wrote: post #60
move-on-by wrote: post #56

> 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. Well, this is awkward - Chrome has deprecated HPKP in favor of…

> if you have a dictatorship, you can require that your CA remains trusted How? I mean, I suppose you could mandate that all computers sold in your country come preinstalled with state-approved monitoring software. But barring that, what's going to stop users from downloading the latest version of Firefox which includes code marking your CA as untrusted?

A police baton

Re: Emacs and TLS

#62

Post by Ajedi32 »

SSLy wrote: post #61
Ajedi32 wrote: post #60

Earlier quoted context omitted.

> if you have a dictatorship, you can require that your CA remains trusted How? I mean, I suppose you could mandate that all computers sold in your country come preinstalled with state-approved monitoring software. But barring that, what's going to stop users from downloading the latest version of Firefox which includes code marking your CA as untrusted?

A police baton

Used against whom? The Firefox/Chrome/Microsoft/Linux developers don't live under your dictatorship.

Re: Emacs and TLS

#64

Post by tialaramex »

simias wrote: post #35
akalin wrote: post #17

Earlier quoted context omitted.

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.

>Do you ever install packages from Emacs? If so, you definitely want that to be at least TLS protected. 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 righ…

This feels like enough, doesn't it? But it's not.

You will also need to sign and timestamp all repository metadata. Otherwise when you learn of bug X and fix it with patch P to produce new package package-V+1 I also learn of bug X, but I ensure my victims don't get told about new package-V+1, they will be told package-V is the latest version and they're now safely up-to-date - but I can exploit them.

If you use TLS I can't meddle with the packages, or the metadata, or anything.

You absolutely can secure everything in your package management system, but it will be a bit trickier than just signing individual packages. Whereas using TLS is enough.

Back in 1995 when anonymous FTP distribution was commonplace, signing packages made a whole lot more sense than trying to get all your mirrors to update to HTTPS. In 2018 this is not so true.

Re: Emacs and TLS

#65

Post by 0xcde4c3db »

sillysaurus3 wrote: post #19
wyuenho wrote: post #18

Earlier quoted context omitted.

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.

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…

> 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.

I don't see where you got any of that. I read point #11 as citing RMS in his capacity as an authority on GNU goals and principles, a capacity in which he still contributes guidance to Emacs and other GNU projects.

Maybe there's some context missing. GNU is an unapologetically political project; decisions are meant to be made not solely in pursuit of some narrow definition of technical superiority or correctness, but being mindful of their effects on the free software movement and human societies in general. From that perspective, it's completely reasonable to be surprised if a GNU project appears to be out of alignment with a major sociopolitical concern of RMS. For example, if GCC 9.0 were released under the original BSD license, people would be surprised and concerned for fundamentally similar reasons.

Re: Emacs and TLS

#66

Post by amake »

vemv wrote: post #38

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 install it from MacPorts with no problems.

Re: Emacs and TLS

#67

Post by kqr »

jancsika wrote: post #14

> It isn't the Emacs way to second-guess our users' needs, definitely not to decide for them what is and what isn't a matter of life and death for them. We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them. > It is IMO unreasonable to make our defaults match what happens in dictatorships that you describe, because that would unnecessa…

> We provide options with some reasonable defaults, and then let users make informed decisions which defaults are not good enough for them.

This is fine for things that are apparent to the user, such as "I don't like this popup window, so I'll configure it to not show", or "I want a better command to split a quoted email, so I'll create that function". But in this case it's about something that happens behind the scenes, which users may not know needs changing.

Now that I've had the relevant comment out of the way, let me be a little more general.

> It isn't the Emacs way to second-guess our users' needs

This is an odd statement to make. Or rather, let me say, Emacs has an approach to this that I haven't been able to explain to myself yet.

It is absolutely true that Emacs tends to ship with so-so defaults, and that this is not a big deal because most users will want to change the defaults anyway. It is also the case that Emacs is very customizeable, so changing any defaults whatsoever has never been a problem.

However, the term DWIM, meaning "do what I mean", originated in Emacs circles. It still flourishes there.

I create dwim forms of commands all the time. There is often a simple contextual, environmental indicator as to whether I want one variant of a command or another. Not encapsulating that check and dispatching into a new command would be silly. That's a core part of Emacs and Lisp culture, in my opinion.

So yes, it is also in fact the Emacs way to guess the users' needs. But transparently.

Re: Emacs and TLS

#68

Post by sillysaurus3 »

wyuenho wrote: post #27
sillysaurus3 wrote: post #25

Earlier quoted context omitted.

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/I…

First of all, I don't have to prove anything

Yes, you do. That's pentesting 101.

Think of it this way. Would it be reasonable for pentesters to say "You're critically vulnerable. But I haven't verified this"?

More times than I can count, when I went back to verify whether I was correct, I wasn't. For subtle reasons. If you haven't put in the work, you don't know whether you are right.

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?

You have never worked in security. The fact that you're shocked at this shows how green you are. I don't mean that in a dismissive or insulting way, but if you'd just go do a stint as a pentester for a year, or talk to some pentesters in the field, you'll quickly stop being shocked at this.

You have a responsibility as someone who is presenting security issues to know what you're talking about. Most people listen to whoever talks the most confidently. And the bare minimum work is proving that the exploits you're presenting are actually applicable to the situation at hand.

Most people don't know security, and very few people will check your work to ensure it's correct. That means when some hobbyist steps up and starts yelling about theoretical issues, it's important to step in and say "Actually, these issues haven't been demonstrated."

What if it takes $100M to MITM someone? Would you say it's still worth being shocked that you're theoretically vulnerable to this? What is the precise cost of someone who actually wanted to MITM someone else using emacs? Have you done the math?

This isn't me downplaying the significance. This is me saying "Do the work." And if you haven't, then you should classify the vulns as low severity. That's what we did whenever we didn't know for a fact that you could own someone's app/box.

Re: Emacs and TLS

#69

Post by move-on-by »

Ajedi32 wrote: post #60
move-on-by wrote: post #56

> 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. Well, this is awkward - Chrome has deprecated HPKP in favor of…

> if you have a dictatorship, you can require that your CA remains trusted How? I mean, I suppose you could mandate that all computers sold in your country come preinstalled with state-approved monitoring software. But barring that, what's going to stop users from downloading the latest version of Firefox which includes code marking your CA as untrusted?

Like I said, the burden at that point is on the users

Re: Emacs and TLS

#70

Post by vemv »

wyuenho wrote: post #51
vemv wrote: post #49

Earlier quoted context omitted.

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)

What about emacs -q ? Does the same issue still happen? If it doesn't, that sounds like a different package is locking up your emacs.

Finally identified the issue - I was adding Marmalade as a repo, which cert is legitimately wrong (Chrome will warn over https://marmalade-repo.org/).

I just removed the repo - I'd say that Melpa won in recent years?

Post reply on HN