Email cannot be encrypted at rest
migadu.com
migadu.com
So we're talking about after it's received and processed by a server.
> Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses...
But you can? Just scan and process before encrypting.
> ...index messages for searching
This indeed is a problem. Encrypting emails individually makes search difficult. Why not just encrypt entire hard drives? Encryption at rest is a very broad term.
> or recover messages when a password gets lost. Not to mention the usability issues of changing passwords and encryption keys.
This has nothing to do with email. This is encryption in general, and these security details are a feature.
> Some other providers automatically encrypt messages as they arrive using users’ public keys. That sounds exciting but in practice that means you cannot access your messages using the webmail unless you pasted your private key into a browser, and have it handled by script and a myriad of third party code. Ouch.
Huh? I haven't heard of copy-pasting private keys. Use passwords. But more importantly, this is specific to webmail, not email in general.
You can't. End-to-end encryption for email means the messages are encrypted by the sending client and decrypted by the receiving client. The server has no chance to scan anything because it cannot decrypt the messages.
>If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself.
I would say their standard for being ‘encrypted at rest’ is including a requirement that they are unable to open it.
This is textbook ‘perfect being the enemy of the good’. There are a lot of threats outside of malicious insiders that could be deterred or slowed down by a practical encrypted storage mechanism.
I agree with the GPG part and that a mail provider can not reasonably create something similar, however they have a weird understanding of "encryption at rest" at the base of their argument why they don't do it.
This is good advice but it just isn't going to happen in practice unless gmail makes it the default for everyone. WhatsApp added support for the Signal protocol and made it the default for all users, now the whole world is communicating with end-to-end encryption.
That would be the end of free gmail.
Indeed, for us, encryption at rest is only meaningful if we cannot access the mails either. However, that is nowhere on the horizon for email. There is a technical way to achieve that, but at a great cost of usability.
Encrypting the disks themselves is trivial and is on our roadmap, but it is nowhere as important as some providers tend to boast. That is why we say "quackery." It is just a "nice-to-have", but in every-day security it matters just as much keeping your car keys in a sealed jar all the time, carrying the jar in your pocket =)
Our data is stripped among multiple disks in RAID10 (obviously), that by itself ensures very little importance to a single disk. Not to mention that if a disk is dead, one would have to find it, identify it belongs to specific user and recover it. This is more likely:
Processes inside of the data center are way more important than an extra layer of encryption for a hollywood heist.
In our so far experience, the biggest threat to users' data are the users themselves. Forgetting passwords, accidentally deleting mails, running malware, choosing weak passwords...
It is interesting that we have never seen this issue raised for Outlook, Gmail, Zoho, Yahoo, AOL and other large providers, who never did or will encrypt at rest.
With hosted services there has to be a chain of trust. We trust our providers (ISP, data centers etc), and our users trust us as a provider.
Furthermore email is generally being observed wrongly today [IMHO]. Email message is a equivalent of an open envelope, a postcard. The only way to security is end-to-end encryption. This way, the need to trust the provider is removed. We could say openly we do have encryption at rest, but that claim cannot be proven by anyone. Same way as Whatsapp says they are E2EE but being a closed protocol, we still have to trust Whatsapp they are telling the truth.
As a provider you have to choose what is worth implementing and what not, what realistically benefits users and what not. Military grade security is silly for email in our opinion. If that is requirement, one should probably not be using email at all. Use Whatsapp :D
Jokes aside, we just try to keep a sane approach to security and not take absolutist stand, all or nothing. It is always a compromise between usability for the user, maintenability for the sys admin and cost. We are not on the expensive side meaning we have to take sane compromises.
If you are willing to pay a premium for absolute security, we can of course do that for you, but we know no one will be willing to pay, and those that do, we probably do not want to have such users, based on our experience from @protonmail users using Migadu. There is tutanota for that purpose btw.
Email was not meant to do many of the things we today try to use it for. It is much more complex than majority will even know and appreciate unless they become providers themselves.
Shifting the burden of indexing e-mail (and decrypting/encrypting the at rest) on the client willing to achieve this?
Edit:
The webmail/imap/pop provider would only have to receive an e-mail and use a client provide public key to encrypt the mail and let it rest.
The webmail client could (in browser) or through their app do the decryption/indexing locally. Could be done with an extension.
This phrase appears multiple times. Wherever it appears, they are wrong. So I love this set of pages. It tells me these are not people to be trusted. They have deep, fundamental misunderstandings of the things they "cannot" provide.
Sometimes, they are mistaking the practical (and useful) for the theoretically perfect. They don't do X because it isn't theoretically perfect, and they can't seem to imagine a way to do it other than the strawman trivial (and bad) way they set up for a smackdown.
Sometimes, they are confusing different issues. Like in this case, what encryption at rest even is, and what it achieves. Or how they seemingly misunderstand ASPs.
I think they are actually probably reasonable tech-wise, and the presentation just needs some help (or some topics not discussed at all). It feels like a Swiss caricature though -- we are always right, if you disagree go away. We only want competent customers. (Where competent == agree that we are correct.) Spoken with a calm air of superiority of course. But maybe what comes off as user hostile to my sensibilities is perfectly cordial to a Swiss person. It would be ok if they weren't actually wrong on the security topics.
I especially enjoy:
No feature parity
We really do not care what service X offers and will not try to match them
I would appreciate to hear the technical reasons why we are wrong on security topics, and less of personal sensibilities. This will contribute to the discussion better and potentially to the email ecosystem :)
> [...] email can be encrypted at rest. We just chose not to do it at the very moment due to the very little added benefit we see in our overall setup.
claiming that everyone who chooses differently is selling quackery is not a good look. The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.
We never say that anywhere, but thank you for the heads up.
> The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.
Indeed, you have all the rights to say so, but we both enjoy the liberties to differ on what "security-in-depth" is.
Well, it reads that way, and you asked for feedback.
Same paragraph has a mixture of E2EE and Encryption at rest topics which may confuse users. We'll separate that.
I think it's unusual to see a company basically say "here's why you might not want to use our product". The ones that do often come across as "here are our issues, but here's why they don't really matter and you should use us anyway". While some parts of the page do maybe seem to do a little of the latter (the "quackery" sections are a good example), the overall tone I get is "here is why we might not be a good fit for you", and I find that rather refreshing.
I'm sure some people will see your "take it or leave it" approach as user-hostile. And perhaps on some level it is. But in my opinion, it's far less user-hostile than hiding those choices/limitations in order to get signups, with the user then finding out about them later and having buyer's remorse.
So kudos for being up-front about it.
I don't have gobs of time but I will at least talk quickly about the 2 specific points since I did raise them and you are kindly enough to want the feedback.
Encryption at rest is not quackery. It protects against theft of physical media. It protects against loss of data when decommissioning media. This happens all the time, in unexpected uncontrolled ways, both when under your direct control and when run in the cloud. No, it does not protect against in-use theft nor the situations you describe. That doesn't make it quackery. It is not encoding; the keys do not need to be stored on the disk being encrypted. (That of course is worthless.)
ASPs are valuable for the same reason oauth is valuable. When you have an account that controls very many services/apps, and you want a specific loss to be limited in scope, you will use an ASP. If you login to mail on 5 machines, and you can detect which one gave up a password, it can be useful. 2FA oauth can be very useful for similar reasons, even if after the authorization it is 1FA afterwards. The implementation of ASPs by Google may be deficient in that they weren't actually limited in scope for a very long time (maybe they still aren't, if they even have them anymore?) but the general concept of the ASP is really like a "out of band" oauth. In your case, I imagine you provide email service only. ASPs would have very limited or no utility for you. oauth grants might be valuable (for 2FA reasons), but I haven't looked at your service to be sure.
How many people could actually be asking for ASPs at all? Just leave this off the page altogether. It screams that you are criticizing some other service, rather than extolling the virtues of your own. It's a bad look.
That sounds more like an E2E encrypted setup where the email is encrypted by the sender before sending it, and the webmail provider stores a passphrase-protected copy of the private key.
In any case, I'm not sure why "third party code" is the problem here. Would they prefer that webmail providers write their own crypto code? Does that include TLS libraries?
Perhaps they mean "code hosted on third party sites", in which case the reaction should be "Why does your site pull in code from third party hosts (and why don't you use Subresource Integrity hashes)?".
That leaves just one possible legitimate complaint, which is that the webmail server can (selectively) serve malicious JavaScript to users. While that risk is about comparable to the risk of running a native client that periodically checks for updates and automatically installs them, I think that the malicious webapp scenario can be mitigated by something like the clever Bookmarklet Bootstrap trick[0]. That has some usability drawbacks, but those might be fixed by something like Hashlink[1].
https://www.acsac.org/2007/papers/161.pdf
---
The increasing centralization of networked services places users' data at considerable risk. For example, many users store their email on remote servers rather than on their own client machine. Doing so allows users to gain the benefit of regular backups and remote access, but it also places a great deal of trust in the server. Since most email is stored in plaintext, a compromise of the server also implies the loss of confidentiality and integrity of the email stored therein. Although users could employ an encryption scheme ( e.g., PGP), such measures are not widely adopted, require action on behalf of the sender, and only provide partial protection (the email headers remain in the clear).
We propose an alternative solution that begins with the server encrypting newly arriving email, including the headers, body, and attachments, using a public-key encryption standard. Unfortunately, this approach also prevents users from remotely searching their email. To solve this problem, we present Secure Searchable Automated Remote Email Storage (SSARES), a novel system that offers a practical approach to securing remotely stored email while allowing privacy preserving searching. SSARES uses a combination of Identity Based Encryption and Bloom Filters, revealing little information about search keywords and queries. SSARES remains largely transparent to both the email sender and recipient. We present an evaluation of our system based on our preliminary prototype, and identify areas for future improvement.
---
But in this case, if user were to forget password, the data would be lost, would it not?