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

Convenient End-To-End Encryption for E-Mail

autocrypt.org

Post reply on HN
Print view View original

21–30 of 190 posts

Re: Convenient End-To-End Encryption for E-Mail

#21

Post by ekianjo »

tptacek wrote: post #13
ekianjo wrote: post #12

Earlier quoted context omitted.

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

Revocation doesn't provide forward security. Standards are what we say they are; almost everyone can use Signal today, and we'd be better of spending the effort to make sure literally everybody can than trying to retrofit security onto SMTP email.

> almost everyone can use Signal today

Except that almost everyone does not. Yet everyone has an email address. I'd say you have to pick your fight. Trying to convert everyone to Signal, even though it will never replace email in what email broadly does and allows, or trying to add encryption to email.

Re: Convenient End-To-End Encryption for E-Mail

#22

Post by mapgrep »

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.”

At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely valuable.

But the biggest issue with your critique is that it proposes treating secure messaging as a special case for which people should just use a special tool. The old, “just use Signal” nonsense. Guess what? People suck at knowing what communications need to be secure, and they suck at keeping mundane conversations from veering into sensitive territory, and they suck at moving conversations from one platform to another. As many systems as possible that they use need to be secured, so that WHEN they mess up — meaning, have the gall to say something potentially sensitive outside of infosec-land blessed tools — the consequences are mitigated.

Security professionals need to meet users where they are. And where they are, to a massive massive unstoppable undeniable extent, is on fucking email. Shitty, plaintext by default, metadata leaking email. Just crying out to be fixed.

And they’re on Twitter DMs and Facebook and god help us Slack. Which is why the people who made Signal put their crypto into WhatsApp. Not because it’s a GOOD IDEA to let Facebook (!!) broker your key exchange and see your metadata — yes, Signal protocol can’t keep metadata away from third parties either, not entirely — but because they had the chance to improve security in an imperfect but good way for millions of people.

The people behind autocrypt took a similarly honest stab at improving email security. If this sort of system were more widely deployed — and i know firsthand that gpg can work well when deployed to an entire workgroup — the security gains would be massive. A huge, imperfect gain. And an essential one even for people who use Signal et al — because every single one of them, dollars to donuts, uses email part of the time. It would be hugely wrong to just leave that on the table.

Re: Convenient End-To-End Encryption for E-Mail

#23

Post by ekianjo »

corndoge wrote: post #18
ekianjo wrote: post #12

Earlier quoted context omitted.

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

on a vps? why? sounds like a great way to make sure at least one entity has access to your mails, encrypted or not, whether you keep your privkey on a diff machine or not

If your emails are encrypted on a vps, they might have access to it but they sure won't be able to decrypt them anyway.

Re: Convenient End-To-End Encryption for E-Mail

#24

Post by tptacek »

ekianjo wrote: post #21
tptacek wrote: post #13

Earlier quoted context omitted.

Revocation doesn't provide forward security. Standards are what we say they are; almost everyone can use Signal today, and we'd be better of spending the effort to make sure literally everybody can than trying to retrofit security onto SMTP email.

> almost everyone can use Signal today Except that almost everyone does not. Yet everyone has an email address. I'd say you have to pick your fight. Trying to convert everyone to Signal, even though it will never replace email in what email broadly does and allows, or trying to add encryption to email.

First, I think you'll be surprised to find how many people use Signal Protocol today, since it's been integrated into one of the world's most popular messaging applications.

Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

Re: Convenient End-To-End Encryption for E-Mail

#25

Post by slavik81 »

tptacek wrote: post #11
dvanduzer wrote: post #10

Earlier quoted context omitted.

The email address format is so useful for domain-based identity. We still haven't squared Zooko's Triangle. What is the practical way to get a function like "document was sent with best effort for some legal purpose to a known party"? Are we just stuck with "login to the secure messaging site" emails from our banks?

Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.

There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox.

How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel?

My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser developers telling you to avoid browsing unknown websites, so they were forced to build a good sandbox.

But, I don't really know. I'm just really disappointed by OS security.

Re: Convenient End-To-End Encryption for E-Mail

#26

Post by lvs »

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

I've seen you as the top commenter on almost every topic of email security, pitching the same arguments.

There is significant demand for content-encrypted asynchronous messaging for all routine purposes. Chat apps do not provide the appropriate platform for real world communication of substance, and security is and must be sought by less dismissive developers than you.

Re: Convenient End-To-End Encryption for E-Mail

#27

Post by tptacek »

mapgrep wrote: post #22
tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.” At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely va…

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make.

It's not my argument that people should use special secure messaging applications when they need security, and email at other times.

It's that we should stop using email pretty much altogether. Like I said: it's archaic. In the overwhelming majority of cases, a messaging application does a better job than store-and-forward email anyways. Which is why a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium.

The one thing we do still routinely use email for --- sending files to each other --- is an iredeemable security disaster that needs to end as soon as possible anyways.

Re: Convenient End-To-End Encryption for E-Mail

#28

Post by microcolonel »

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to.

There is functionally no difference between the SMTP/IMAP and HTTPS security models.

Re: Convenient End-To-End Encryption for E-Mail

#29

Post by tptacek »

lvs wrote: post #26
tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

I've seen you as the top commenter on almost every topic of email security, pitching the same arguments. There is significant demand for content-encrypted asynchronous messaging for all routine purposes. Chat apps do not provide the appropriate platform for real world communication of substance, and security is and must be sought by less dismissive developers than you.

Signal Protocol is designed for asynchronous messaging.

Re: Convenient End-To-End Encryption for E-Mail

#30

Post by tptacek »

slavik81 wrote: post #25
tptacek wrote: post #11

Earlier quoted context omitted.

Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.

There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox. How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel? My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser…

There's an enormous difference, and it's not just the sandbox; it's also that the viewer application is:

* Written in a language other than C

* Doesn't have any access to your local system by design, not as a consequence of sandbox rules

* Is maintained serverside, so everyone gets patched instantly

Post reply on HN