Comment by Sniffnoy
7 years ago
So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email.
E.g., things distinguishing how email is used from how text-messaging is used:
1. Email is potentially long-form. I sit down and type it from my computer. Text-messaging is always short, although possibly it's a series of short messages. A series of short emails, by contrast, is an annoyance; it's something you try to avoid sending (even though you inevitably do when it turns out you got something wrong). Similarly, you don't typically hold rapid-fire conversations over email.
2. On that point, email says, you don't need to read this immediately. I expect a text message will be probably be read in a few minutes, and probably replied to later that day (if there's no particular urgency). I expect an email will be probably read in a few hours, and probably replied to in a few days (if there's no particular urgency).
3. It's OK to cold-email people. To text someone you need their phone number; it's for people you know. By contrast, email addresses are things that people frequently make public specifically so that strangers can contact them.
So what am I supposed to do for secure messaging that replicates that? The best answer I've gotten for this so far -- other than PGP which is apparently bad -- is "install Signal on your computer in addition to your phone and just use it as if it's email". That's... not really a satisfactory answer. Like, I expect a multi-page Signal message talking about everything I've been up to for the past month to annoy its recipient, who is likely reading it on their phone, not their computer. And I can't send someone a Signal message about a paper they wrote that I have some comments on, not unless they're going to put their fricking phone number on their website.
So what do I do here? The secure email replacement just doesn't seem to be here yet.
Your point 1 especially speaks to me. Phone-based messaging in general isn't appropriate for the things I would most like to be kept private between me and a recipient, because those sorts of things can't be created on a phone. I've found PGP pretty good for making that happen, when I'm working with someone who a) uses PGP also and b) exercises some caution when using it. I haven't found an option that I can trust that will work for me.
I strongly agree with this; email is not instant messaging, and there is not yet any secure replacement for email.
We need a modern design for a successor protocol to email, and no one is working on it because they prefer instant messaging (or think other people do).
Google has tried with Wave but failed. I don't think it can be done.
Everything would have to support SMTP as a fallback for the lot of people that just don't care and thus couldn't actually improve.
I think we're more likely to "accidentally" end up there via E2EE document collaboration tools that are in development now.
One day, a while after they become usable and common, people will just realize they've been sharing documents E2EE in place of sending email, and they'll be using it for basically everything that matters.
It would be a proper restart and allow for significant improvements in usability and security and everything else.
Can you point me to examples of such tools?
1 reply →
Do you feel like PGP is a good way to cold email people in practice? (I'm not trying to put words in your mouth, but that sounds like what you're saying.)
> Do you feel like PGP is a good way to cold email people in practice?
Not OP but I can definitely say that's a yes from me after doing this repeatedly. I cold email people once a month or so, and if it is to do with anything sensitive I'll check to see if a public key is available for them (on their website is best, else I check a public key server and use that key as long as there is only one listed).
I get a better response rate from PGP/GPG users too, I can only recall one not responding to an encrypted message and I sent a follow-up message unencrypted which they responded to.
I think it's important to send PGP messages for ordinary communications whenever possible, because this normalizes it and may increase the workload for those trying to defeat it.
Good question. Not sure. Although I don't see why I wouldn't, if they have a PGP key listed? (I guess there is some question over whether the listed key is actually them?) But my point is that, well, email is a good way to do that, and Signal isn't, so I'm going to use email rather than Signal.
Honestly, I wouldn't focus on (3), because as I see it, if you can replicate the feel of email, things like (1)-(2), so that it can replace email in contexts without (3), then (3) will just come naturally as it slowly replaces email.
Edit: All this is assuming it isn't tied to a phone number or something similar, of course!
How does one list a public PGP key, is there a verified central listing service?
9 replies →
"mostly cold" email to a security email address listed on a website is probably the only use I've ever had to PGP encrypting email to someone I hadn't already been communicating with... (But I can imagine other scenarios. I bet Snowden's cold email to Greenwald was encrypted...)
Trust on first use is not an uncommon security practice. Imperfect but in many times the best alternative, and a good solution while we wait for a replacement to gain traction.
Why wouldn't it be?
3 is incorrect for encrypted email: you cannot email someone unaware without their consent and expect them to willingly and ably participate in decrypting.
Why not? I mean, that's what publicly listing your public key is for, right?
Nope. I have at least three public never-expiring keys that I am unable revoke and that remain listed as valid because the keyservers don’t occasionally revalidate proof of ability to decrypt.
4 replies →
I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext.
I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt every little thing
> It's not like I can read your emails unless I break into Google's servers, no?
Well, first of all, "breaking in" isn't the only way someone might get access to data on Google's servers. There are such thing's as subpoenas, not to mention that it is possible a Google employee might abuse access to servers. And then I would be _very_ surprised if google doesn't use the content of your emails for advertisement and tracking purposes.
Furthermore, unless both parties are using gmail, the email will be stored at least temporarily on other mail servers, which may be less secure (and you might not even know who controls them).
> And then I would be _very_ surprised if google doesn't use the content of your emails for advertisement and tracking purposes.
That would go against their own privacy policy. But they are one change away from doing it.
11 replies →
In modern practice, email is sent over TLS sockets already. Any good email client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the past few years, even the MX-MX transfers in the backend have started to become protected (albeit mostly opportunistically at this point, I believe) with TLS.
So the only people who can read email are you, your counterparty, your ESP, and your counterparty's ESP, assuming the email providers are following good practice.
This is an excellent explanation overall, I do however think that it's important to note that opportunistic STARTTLS is vulnerable to downgrade attacks by mitm. Since this would have to be a mitm of e.g. Gmail it's not trivial by any means, but neither is it completely out of reach (see for example the periodic rerouting of the internet caused by odd BGP advertisements).
One further note is that you can know post-hoc if an email was delivered to Gmail via TLS by the presence or absence of a red lock in the Gmail app or web UI.
8 replies →
> Any good email client should prohibit you from
Most e-mail servers required a login (regardless of fetching or sending), and it would take a real incompetent sysadmin to allow that to happen in the clear.
> It's sent over https, isn't it?
That's actually more complicated than that.
If you're using a web mail, your connection to the mail provider most likely uses HTTPS. That is, HTTP over TLS. When the mail is sent, it depends whether the recipient uses the same provider or not. If it's the same provider, well, protocols are irrelevant. If not, it will usually be SMTP over TLS (minus any potential problems with STARTTLS).
The main problem with that is that the mail is not encrypted on the various servers it goes through. Only the server-to-server connections are encrypted. So your provider can access your email, and so can the recipient's. When that provider's business model is reading your emails so it can send you targeted adds, this is less than great. (Yes, Google reads your emails. They try to reassure you by telling you their employees don't read it, but the fact the process is automated actually makes it worse.)
Also, it might surprise some people just how many servers an email travels through to get to its destination. I just grabbed a random mail from a mailing list I'm on (generally a worst case scenario) and it had 7 Received headers. Every mail server is supposed to add a Received header when the mail passes through but there's no way to enforce that, so all I can really say is that mail probably passed through at least 7 servers on it's way to my inbox.
Each one of those hops may or may not have talked TLS to the next hop. Each one probably wrote the mail out to a disk based mail queue in plaintext. There is nothing preventing any of those 7 servers from keeping around that mail even though they forwarded it on. There is nothing preventing them from indexing the mail for spam or marketing purposes.
Any sysadmin can read your email, in general. There's no holistic "this email can't be read by anyone other than the recipient" as a solution, which is what a lot of us are aiming for. Things like protonmail and tutanota get really close, but they're proprietary solutions and don't work for "the many" (such as yourself) who use a hosted solution such as Gmail, who seem to have no interest in providing an open solution.
I don't want my emails to be readable by Google, yet they will when people I communicate with are using Gmail.
Mail doesn't use HTTPS. But even if TLS is enabled, you don't know that all the time.
The old ‘security is hard so let’s not do it’ argument. Emails are not properly encrypted in transit and are available for access at the provider if a court decides to grant a warrant. That might not be enough protection for everyone.
It is possible for a determined individual to withstand targeted attacks if he’s careful and willing to make the sacrifices that come with the territory.
Are you assuming everyone uses Gmail or do you not know how SMTP works?
You might be surprised just how many mail providers support STARTTLS for email, at least opportunistically.
https://www.fastmail.com/help/technical/ssltlsstarttls.html
2 replies →