Hacker News new | ask | show | jobs
by alfiedotwtf 2460 days ago
Encryption, in email? lol...

This is what happens when end-to-end encryption isn't the default in communications software. All email providers are vulnerable to this bar none.

2 comments

Honestly I'd like to see one of the webmail providers do a decent attempt at gpg. The web migrated from a primarily unencrypted state to an encrypted one - it's not impossible with the right UX.
This is never going to happen because it doesn’t work very well for consumers, and works even less well for businesses.

For consumers, owning the encryption keys means account recovery is impossible when they inevitably lose their keys. IM services can get away with it, because losing your IM history is not nearly as serious as losing your inbox.

For businesses, you’re not going to be able to sell a service that makes filtering impossible. This is bad for consumers too, but an absolute deal breaker for most businesses.

> that makes filtering impossible

... including spam filtering, which matters somewhat for consumers, too.

Then there's the issue of search - with webmail you have no realistic choice but to rely on server-side search, and the same issue likely applies on phones even when using a dedicated mail app. (And indeed ProtonMail currently only offers meta-data search, but no full text body search)

I didn’t specifically say spam filtering, because there’s technically lots of spam filtering you can do with only metadata. But yeah you’re right, any form of server side content filtering (including search) would be impossible.
The attempts have been made, but for some reason it hasn't taken off.

https://github.com/google/end-to-end

https://github.com/YahooArchive/end-to-end

These projects depend on some way to discover public keys, but Keybase is not federated and https://github.com/google/keytransparency/ is way behind schedule.
The web is encrypted in transit but most data is probably stored in an unencrypted form, much like email.
The web is _partly_ encrypted in transit. To the point where it hits the closest cloudflare (or other edge) server. From then on it's often unencrypted the rest of the way to the real webserver.

Yes, it would be possible to encrypt email too but it would involve changing every email client and server there is, and there are quite a few of them. And a public key repository for everyone to be able to find the correct key for each receiving adress. Mailing list servers and other group mail would be particularly fun to solve.

Given that you mentioned CloudFlare, they actually encourage using Full SSL (Strict), which requires a valid certificate from the origin server to the edge server. You can also get them to issue an SSL cert for you if you don't want to deal with that yourself. It expires in 10 years by default, but can be revoked easily in case of key compromise.
flowcrypt for gmail is quite good. https://flowcrypt.com/
ProtonMail?
Communication between a ProtonMail customer and a non-customer, there is no end-to-end encryption.

Communication between ProtonMail customers, you still have to trust that their UI hasn't been MiTM'd.

Hardly a major provider though.
Not sure why I'm getting downvoted. Prove me wrong.
I don't see how this could happen at Tutanota
From https://tutanota.com/faq

"Your private key is encrypted with your password. This way your login password receives the status of the private key."

"Your password is never transmitted to the server in plain text. It is salted and then hashed with bcrypt locally on your device so that neither the server nor we have access to your password."

What's stopping them (or being commandeered) to serve you modified javascript which sends them your password, or this being done via an unsanitised email viewed via their web UI?

Having worked for two email companies for over 10 years, I know not trust email providers for privacy.

> What's stopping them (or being commandeered) to serve you modified javascript which sends them your password, or this being done via an unsanitised email viewed via their web UI?

Thinking about this more, the threat model here was an insider. This is something that Tutanota wouldn't be able to prevent with its advertised services given the same situation.

Client side hashing + SRI