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

71–80 of 190 posts

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

#71

Post by stephenr »

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…

> Most email users get their email from a website.

I'd argue thats not the case. Business users are likely still using outlook/etc. Personal users are likely using their smart phone for email.

Also by what standard is pgp "the most popular". Its popular with technical people sure, but there is fuck all support in commercial mail clients. S/mime is supported, and due to ca roots, doesnt require you keep using the sams private key - you could use a new cert every 3 months ala LE if you wanted

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

#72

Post by sjwright »

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…

It's the operating system's job to protect itself from userland, as well as to protect userland from other userlands. It's generally not its job to protect your documents from your applications.

Normal people don't worry about malware rooting their OS. Normal people worry about malware ruining their un-backuped photos and work docs, something that few operating systems dare protect users from.

(Which is why the iOS model of computer security is IMO a sleeper breakthrough, and why I always always recommend iPads/Chromebooks to people I wouldn't trust to not download Comet Cursor.)

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

#73

Post by Valodim »

microcolonel wrote: post #69
tonyarkles wrote: post #64

Earlier quoted context omitted.

I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement. The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot s…

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

> It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header)

We get fairly close here if we can get providers to DKIM-sign Autocrypt headers, like Posteo already does.

E-Mail has a lot of baggage though, and we don't expect to get everything done overnight. Legacy is important, and development resources in this area are realistically very limited. Still, we feel like we have a reasonable start.

> It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?).

I think the best we can do here is to make providers sign keys during transit, and increase attacker risk by allowing users to verify their communications at any point.

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

#74

Post by cmroanirgo »

dvanduzer wrote: post #10
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…

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?

> The email address format is so useful for domain-based identity.

Agreed. But this is also where the problems of spam begin.

Perhaps if we chose to 'phase out' MX records in DNS for something new, say 'MSG'. A domain could then have an MX as well as a MSG server... A local MTA would route to the 'new shiny messaging system', so that clients could use the one system to read emails. Remote MTAs could also lookup and see if there's a 'MSG' on the receiving end and talk to it instead, rather than the designated MX, increasing the security. (In this case the sending user would still be sending via a normal email client)

Ideally, everyone will migrate over to MSG, upgrading the world smoothly.

(I figure something like this has already been tried tho...?)

2c.

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

#75

Post by aplorbust »

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…

"Unpopular but probably very true fact: ..."

Another unpopular but very true fact:

"Email", the technology, not the business, can be defined as party A depositing an RFC811 formatted message on the computer of party B. Email requires only a reachable IP address.

This definition of email can be implemented withut using third party intermediary SMTP servers. Sender and reciever SMTP servers can communicate directly, without so-called "store and forward". I conducted an experiment of "peer-to-peer" email: both sender and receiver are on a Layer 2 overlay, i.e., /dev/tap0 with private IP address, each running their own smtp server bound to tap0. qmail was used, it accepts IP addresses; no ICANN domainnames were needed but private DNS names were also tested. All traffic going through tap0 was encrypted. (Note: I did not use OpenVPN.) It worked as expected. The Layer 2 approach I used would be limited as to the size of networks but would probably accomodate the size of a persons cricle of friends, family and colleagues; addtionally small virtual LAN networks can be bridged to create larger internetowrks. It would probably work with encryption at Layer 3 as well, without such limitations. Maybe people have/will do this with Wireguard.

Whether or not this works for the email "business" is irrelevant. Whether or not this is practical for anyones use case is also irrelevant to this comment. The question is whether email can be encrypted. For me, the experiment proves it can, in at least one way.

Of course, once party A and party B have an end-to-end connection, e.g., over a "virtual LAN" over the internet, then there are many more interesting possibilities for communication than just "email".

Email has evolved in the way it is implemented, and IMO it can evolve further. If I recall correctly from reading old RFCs, I believe the original "email" was actually done via FTP. One deposited mail by appending to a file on the recipients computer. Of course in those days that computer was timeshared by many recipients because computers were too expensive for individual recipients to own. This is no longer true today. Computers are affordable for all recipients. (Yet, with respect to email, recipient still share computers. These are run by "email providers".)

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

#76

Post by jancsika »

tptacek wrote: post #27
mapgrep wrote: post #22

Earlier quoted context omitted.

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…

> It's that we should stop using email pretty much altogether. Like I said: it's archaic.

Claiming that some piece of software or set of protocols is archaic is probably the least persuasive way to argue against continuing use.

> [...] with occasional cold inbound introductions that quickly transition off into some better medium.

Cold inbound introductions alone are a reason for continuing plaintext email well into the future.

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

#77

Post by jopsen »

brongondwana wrote: post #58
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 agree with you on everything here except for your "don't use email" point in the followups. For 99+% of people, being able to recover your archive when you forget your password or lose your device is more valuable than being secure against a state-level adversary. I think the security debate around email suffers from an over-supply of confidentiality absolutists, in which both integrity and availability take the ba…

Indeed just getting most senders and servers to use TLS would be a good start.

That said, lots of businesses deal with sophisticated attackers who are trying to steal trade secrets, patents in progress, etc. Sometimes these attackers are state sponsored too (I would definitely suspect China, US and Russia for this kind of crimes).

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

#78

Post by pvg »

jancsika wrote: post #76
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…

> It's that we should stop using email pretty much altogether. Like I said: it's archaic. Claiming that some piece of software or set of protocols is archaic is probably the least persuasive way to argue against continuing use. > [...] with occasional cold inbound introductions that quickly transition off into some better medium. Cold inbound introductions alone are a reason for continuing plaintext email well into t…

It's surely somewhat more persuasive than merely calling a constructively-argued position you disagree with unpersuasive.

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

#79

Post by compsciphd »

chakalakasp wrote: post #68
brians wrote: post #34

Earlier quoted context omitted.

I’m pretty sure I want a big searchable archive, though. That doesn’t seem compatible with most of these security-oriented message schemes.

Protonmail seems to pull it off. Though at the moment encryption only works inside their system. They are actively working to implement the ability to send secure messages to people outside their service with GPG, though. I believe the CEO said it’d be ready by early 2018.

Please correct me if I'm wrong, but they don't let you search in a protected manner.

They enable searching of data they keep unprotected (the metadata so to speak)

And proton mail bridge seems to be an "offline" (i.e. offline to them) email search engine that you run yourself, so it downloads your emails, and makes them fully searchable, but to do that, is also keeping them in an insecure state.

compare to

https://www.cs.columbia.edu/~angelos/Papers/2007/SSARES_ACSA...

and

http://sprout.ics.uci.edu/pubs/05628733.pdf

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

#80

Post by antris »

brongondwana wrote: post #60
opmac wrote: post #57

Earlier quoted context omitted.

Oh look, another "middlebrow dismissal" ( https://news.ycombinator.com/item?id=4693920 ) upvoted to the top of a HN post. Color me surprised.

It's not a "middlebrow dismissal", it's a well reasoned argument about why this whole area of work is doomed to failure for structural reasons which can't be solved.

The thing is, there's different degrees of failure. You can make email much more secure than it already is for a massive amount of users without sacrificing user experience. Just because it's not possible to make email the most perfectly secure messaging system invented by man doesn't mean we shouldn't make it more secure.
Post reply on HN