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

181–190 of 190 posts

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

#181

Post by driminicus »

a3_nm wrote: post #105
tptacek wrote: post #27

Earlier quoted context omitted.

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…

> 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 Just wanted to point out: that's certainly not true for everyone. The overwhelming majority of my work communication is done by email, and an important part of my social communication with friends and…

I'd argue matrix.org is a good contender for that space, federated, selfhosted and steadily growing, with megolm for end to end encryption (based on signal axolotl whatever the name is).

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

#182

Post by upofadown »

e12e wrote: post #167
upofadown wrote: post #140

To save some hunting around, here is the description of what is being proposed here: * https://autocrypt.org/examples.html Basically you include your public key in a "Autocrypt:" header line added to all messages you send out. Then encryption transparently happens. So we give up some protection against MITM attacks but get protection against passive surveillance for people who are not willing or able to participate i…

How is this better than signing outgoing email, and default to encrypt to senders who sign their mail?

A signature does not give you a public key. You actually need the pub key to verify the signature.

I think one could still ask why you couldn't just use a mime section for the public key in the same way that signatures are often attached.

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

#183

Post by tptacek »

e12e wrote: post #177
tptacek wrote: post #174

Earlier quoted context omitted.

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,…

Secure messengers might use TLS (though probably not HTTPS) to connect to servers, but messages themselves are independently encrypted: they don't rely on TLS for message encryption.

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

#184

Post by e12e »

upofadown wrote: post #182
e12e wrote: post #167

Earlier quoted context omitted.

How is this better than signing outgoing email, and default to encrypt to senders who sign their mail?

A signature does not give you a public key. You actually need the pub key to verify the signature. I think one could still ask why you couldn't just use a mime section for the public key in the same way that signatures are often attached.

The implied missing steps are a)publish key to keyserver network, and b) get fingerprint from signature and look up key on keyserver network.

Bundling public key with every mail "feels" a bit heavy handed - given the key server infrastructure that already exist. (and special-casing "mail to new receiver" seems cumbersome. At least considering you'd probably want to sign all outgoing mail anyway[1]).

[1] Ok, maybe not your bomb threats if they're designed to be anonymous - but that's getting into one of the other issues with pgp - non-repudiation.

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

#185

Post by e12e »

tptacek wrote: post #183
e12e wrote: post #177

Earlier quoted context omitted.

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,…

Secure messengers might use TLS (though probably not HTTPS) to connect to servers, but messages themselves are independently encrypted : they don't rely on TLS for message encryption.

Right. And gpg messages are also independently encrypted, although subject isn't scrubbed by default, and some routing information leaks by default (although eg Mixmasters exist as one approach for mitigating the latter to a certain extent. All system will need to have some routing information. Come to think of it, gpg+usenet might be "better" example of "old tech" secure messaging).

Ed: i suppose the question.becomes if new systems rely on tls to help obscure meta-data or not; like what mail+gpg does.

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

#186

Post by tracker1 »

a3_nm wrote: post #105
tptacek wrote: post #27

Earlier quoted context omitted.

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…

> 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 Just wanted to point out: that's certainly not true for everyone. The overwhelming majority of my work communication is done by email, and an important part of my social communication with friends and…

Not specifically to you, but want to point out that you cannot have secure + decentralized + anonymous without being subject to poisoning attacks.

And "secure" is only relative to "convenient" for the most part. Most people will sacrifice the former for the latter.

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

#187

Post by jlgaddis »

tonyarkles wrote: post #150
microcolonel wrote: post #69

Earlier quoted context omitted.

> But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. Don't accept non-STARTTLS traffic. Google doesn't, you shouldn't have to either. STARTTLS is widely available, and simply needs to be configured. Encouraging everyone to configure STARTTLS correctly is the easiest win we'll have. And I hope you don't take what I said to mean that IMAPS and SMTP…

Google won't accept inbound mail (from an MTA, not an MUA) that doesn't do STARTTLS? If that's true, I'm both impressed (at their resolve to make the Internet a better place), and concerned that messages from old ISPs that haven't upgraded in a decade won't ever reach my GMail account.

Google does accept it. To do otherwise would violate the RFCs.

They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.

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

#188

Post by tonyarkles »

jlgaddis wrote: post #187
tonyarkles wrote: post #150

Earlier quoted context omitted.

Google won't accept inbound mail (from an MTA, not an MUA) that doesn't do STARTTLS? If that's true, I'm both impressed (at their resolve to make the Internet a better place), and concerned that messages from old ISPs that haven't upgraded in a decade won't ever reach my GMail account.

Google does accept it. To do otherwise would violate the RFCs. They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.

Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates)

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

#189

Post by jlgaddis »

tonyarkles wrote: post #188
jlgaddis wrote: post #187

Earlier quoted context omitted.

Google does accept it. To do otherwise would violate the RFCs. They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.

Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates…

Sorry, you misinterpreted my reply. I agree with you completely. I replied mostly to point out that microcolonel's statement that

> Don't accept non-STARTTLS traffic. Google doesn't, ...

is incorrect -- as you doubted:

> If that's true, I'm both impressed ...

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

#190

Post by tonyarkles »

jlgaddis wrote: post #189
tonyarkles wrote: post #188

Earlier quoted context omitted.

Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates…

Sorry, you misinterpreted my reply. I agree with you completely. I replied mostly to point out that microcolonel 's statement that > Don't accept non-STARTTLS traffic. Google doesn't, ... is incorrect -- as you doubted: > If that's true, I'm both impressed ...

Oh! Apologies, didn't notice that you weren't the parent. Cheers :)
Post reply on HN