Convenient End-To-End Encryption for E-Mail • Hacker News Board

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

#171

Post by mark242 » Sun, Jan 07, 2018, 10:34 PM UTC

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…

Email can be made secure, it's just that by default it's insecure and there isn't a Google/Mozilla/Microsoft/Apple conglomerate to penalize SMTP servers by showing "Insecure" in an email display/etc.

* Most mail transport agents can require connections to use TLS, but nobody does because they're afraid of denying incoming messages and because it can be difficult to install a certificate for an MTA, so smaller providers just don't. There should be a LetsEncrypt for mail servers and by default the various package managers and distributions should not install a mail agent that allows non-TLS connections.

* It is possible to store mail messages encrypted at rest, but only by using an encrypted filesystem-- I'm not aware of any MTA that will do this itself. Obviously that needs to change.

* Providers can force TLS connections for IMAP. This is surprisingly easier these days given that most end user mail clients will auto-negotiate these connections.

There's your E2E encryption. This doesn't get you encryption on the final destination, but that's a separate issue.

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

#172

Post by tptacek » Sun, Jan 07, 2018, 11:19 PM UTC

mark242 wrote: post #171

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…

Email can be made secure, it's just that by default it's insecure and there isn't a Google/Mozilla/Microsoft/Apple conglomerate to penalize SMTP servers by showing "Insecure" in an email display/etc. * Most mail transport agents can require connections to use TLS, but nobody does because they're afraid of denying incoming messages and because it can be difficult to install a certificate for an MTA, so smaller provide…

For the nth time on this thread: TLS does not provide end-to-end encryption for email. End-to-end encryption means you can read your mail, and the person who receives your email can read it, and no system in between can ever see the plaintext.

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

#173

Post by tptacek » Sun, Jan 07, 2018, 11:24 PM UTC

aftbit wrote: post #96

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…

Unfortunately, Signal is not decentralized or federated (for good reasons[1]). Email is. This is an important feature for those of us who worry about the growing centralization of the web, as well as the very many users who still mainly use email for communication. When you leave a job, you may not keep your email address, but at least you can still communicate with people across organizational boundaries. Anyway, ev…

To a pretty good first approximation zero percent of messaging users care about federation.

It's clear to me why "don't bother encrypting email" upsets nerds on message boards. But if you're going to trade getting the maximum number of messages safely encrypted for a deeply uncertain future in which most email is somehow reliably encrypted, you have priorities other than end-user safety --- and, I would argue (but do accept that I can't do so conclusively) priorities other than security engineering.

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

#174

Post by tptacek » Sun, Jan 07, 2018, 11:28 PM UTC

e12e wrote: post #165

tptacek wrote: post #90

Earlier quoted context omitted.

That's strict transport security between hops . There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supp…

It doesn't make sense to talk about whether HTTPS is end-to-end encrypted. Sometimes it is, sometimes it isn't. If you're exchange secrets directly with a web application that doesn't leave the application's secured deployment environment, TLS is all you need. But if you're exchanging secrets with another person using a server as a mediator --- as is the case with web chat and web email systems --- then it's not.

I don't know why we'd bother with fussy contraptions involving special email addresses that nobody knows about, let alone uses. We have secure messaging systems today, systems billions of people already use, they're designed from the ground up to handle these problems, and so they're much better at security than any email system we can even reasonably come up with might be.

Why are we wasting time trying to make people feel safer emailing secrets? We should get them to stop doing that at all.

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

#175

Post by tptacek » Sun, Jan 07, 2018, 11:29 PM UTC

cvwright wrote: post #98

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…

This argument is always a mess. I think a lot of the problem stems from not having a clear definition of what we mean when we say "email". Some of these complaints seem to be about SMTP, some are about client programs, and some are about PGP. Your individual concerns are all valid, but that doesn't mean they come together to make a compelling argument that email will always be horribly insecure. Heck, you could proba…

Look at X3DH, Double Ratchet, and Sesame and sketch for me a comparably secure system that uses SMTP as the transport and that doesn't reduce SMTP to a tunneling mechanism for an entirely different protocol.

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

#176

Post by type0 » Sun, Jan 07, 2018, 11:34 PM UTC

e12e wrote: post #165

tptacek wrote: post #90

Earlier quoted context omitted.

That's strict transport security between hops . There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supp…

Yeah, but we need email 2.0, encrypted by default. Maybe not call it user+secure@example.com but something like user@@example.com

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

#177

Post by e12e » Mon, Jan 08, 2018, 12:02 AM UTC

tptacek wrote: post #174

e12e wrote: post #165

Earlier quoted context omitted.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supp…

It doesn't make sense to talk about whether HTTPS is end-to-end encrypted. Sometimes it is, sometimes it isn't. If you're exchange secrets directly with a web application that doesn't leave the application's secured deployment environment, TLS is all you need. But if you're exchanging secrets with another person using a server as a mediator --- as is the case with web chat and web email systems --- then it's not. I d…

It's my understanding that most of these secure messaging system relay via servers speaking https - and their distinctive feature is that the clients are distributed as self-contained apps, that wrap the complexity, and label "signal-protocol over https rpc" as just "signal" (similar for WhatsApp etc).

Why is it hopeless to do the same for email? Take a sane protocol subset, add a convention protocol for encryption, and ship it as "secure email"?

It is a tautology that a "secure mail app" that allows "traditional email interop" cannot make strong privacy guarantees, just like when using WhatsApp you give up federation and networking-as-a-utility (you're completely beholden to a provider that you don't even have a proper contract with, let alone the opportunity to seamlessly move providers / self-host / federate while maintaining global addressing and data portability).

I think that's part of the disconnect in the discussion - wrapping a sane protocol selection in an opaque app along with a saas/paas silo that limits addressing, routing and federation is OK for some arbitrary subset of not-by-themselves secure protocols, but any suggestion that reusing elements of email is dismissed as "can't be done" (or "can't be done, because webmail", while "can't be done because messenger.com" seems absent).

We've already done meta-data wrapping for email, with one, perhaps flawed approach:

https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer

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

#178

Post by e12e » Mon, Jan 08, 2018, 12:10 AM UTC

type0 wrote: post #176

e12e wrote: post #165

Earlier quoted context omitted.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls). The sender needs a smtp server, usually "their own", and usually (today) supp…

Yeah, but we need email 2.0, encrypted by default. Maybe not call it user+secure@example.com but something like user@@example.com

Sure, the reasoning for username+secure is that most mail servers are set up to forward that, so if I send a pgp encrypted mail to user+secure@example.com today, user@example.com will get it, and can read it using regular mail+pgp setup.

The server could then be augmented to drop unencrypted mail to "+secure" - and mail user agents could handle pgp keys and "+secure" addresses especially.

For example split mail delivered to user@ and user+secure@ in a "insecure/postcard/public" view and a "private/personal/letter-in-envelope" view.

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

#179

Post by slavik81 » Mon, Jan 08, 2018, 6:36 AM UTC

tptacek wrote: post #30

slavik81 wrote: post #25

Earlier quoted context omitted.

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

Regarding your first point, would a website written in C and compiled to JavaScript have the same security issues? I'm wondering whether a middle layer can fix the problems you have with C, or if they're inherent to any use of the language.

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

#180

Post by PuffinBlue » Mon, Jan 08, 2018, 9:40 AM UTC

ryukafalz wrote: post #148

PuffinBlue wrote: post #127

Earlier quoted context omitted.

Huh, i think you've just identified (for me at least) the crux of the issue. What messaging system other than email allows for topic based discussion? I guess you could abuse groups to donsomething similar, but its not wuite the same. The underlying one person to one person philosophy of messaging apps is infuriating for organised discussion over time. It makes finding info discussed harder too. Does anyone have any…

>Does anyone have any suggestions for messaging apps that don't put person to person front and center but topic discussion like email? IRC, Riot (Matrix in general), Slack, Discord, Rocket.Chat. There are quite a few. I'm partial to Matrix, personally - you can invite a few friends for a room, and naming that room/setting a topic are optional, so either use case is fairly natural.

Hmm, not really. All those apps fall into the trap of following a UX design where it's all about a group or person and the conversation within.

IRC is channels, Slack is channels, Riot seems to just basically be IRC, Discord is another take on the same genre.

None of them give you what email gives you.

With email there's not a person or group in sight in the UX, save for perhaps a 'from' entry in the thread list. It's all about info. I can start 100 conversations with the same person and have those threads organised into a timeline separately from each other. I can then also arrange them into arbitrary collections.

I can possibly achieve something sort of like this by abusing groups or channels in these other apps, but then what? I just get a sidebar full of the things - what do I do with them? Can I search them and the info within from a global panel? Can I organise them into folders? Copy them to other accounts with a simple drag and drop?

Email has quite a different focus than all those apps you mentioned which is probably why nothing has replaced it.