6 ms·

Email cannot be encrypted at rest

33 points by capableweb 6y ago

rsa25519 6y ago
> at rest 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.
- chongli 6y ago
  But you can? Just scan and process before encrypting. 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.
  - JshWright 6y ago
    End-to-end encryption and encryption at rest are two very different things.
    - jb_gericke 6y ago
      Not clear if the author is referring specifically to mail services like gmail here. Full disk encryption would indeed encrypt my email at rest (assuming I'm syncing mail locally on my laptop with FDS turned on).
- jcims 6y ago
  The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA: >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.
  - Jon_Lowtek 6y ago
    yeah that gets clear when they talk about their certified physical security: there is a strong assumption that drives can not be stolen and will be destroyed at their EOL. Such assumptions often don't hold. Encryption and physical protection are not redundant, they are defense in depth. 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.
    - PeterisP 6y ago
      In addition to protecting against losing hard drives, 'encryption at rest' (as applied in e.g. card industry) can also protect the data from an attacker who gets full access to the database through e.g. a SQL injection, if properly implemented.
  - matheusmoreira 6y ago
    > please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself 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.
    - Jon_Lowtek 6y ago
- Cantbekhan 6y ago
  Couldn't the indexing issue be solved by only having the client/user do the indexing while e-mails are stored encrypted on the server? Ideally on an encrypted device which will keep/maintain the indexing. 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.
Simulacra 6y ago
Email can certainly be encrypted at rest, server or client side, maybe not as quickly or with little resources, but it can be encrypted.
asdjklqwwq 6y ago
About 2FA. Protomail does have it, by having their own proxy app on client's side. Your mail apps do not connect to mail server directly, instead, they connect to the proxy app, and proxy app is authed with 2FA.
skoll43 6y ago
whats the problem with GnuPG and mailvelope ?
- Jon_Lowtek 6y ago
  none - but they are not "encryption at rest by the mail server provider" which is what the article is about
niftylettuce 6y ago
If you just need email forwarding with a custom domain: https://forwardemail.net https://forwardemail.net (creator here)
deleted 6y ago
[deleted]
dane-pgp 6y ago
> 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. 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]. [0] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [1] https://github.com/w3c-ccg/hashlink https://github.com/w3c-ccg/hashlink
1970-01-01 6y ago
False!
Ayesh 6y ago
This article is brutally honest. It's the first time I see their service, and they sure offer an honest service with no BS.
compsciphd 6y ago
paper I had an idea for that was mostly done by an undergrad (now a professor) https://www.acsac.org/2007/papers/161.pdf 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. ---
- dejan 6y ago
  Thank you for posting this. Interesting! But in this case, if user were to forget password, the data would be lost, would it not?
  - compsciphd 6y ago
    I mean, if I ran my own server and forgot the password to it, the data could be lost as well....
jiveturkey 6y ago
> We refuse to sell quackery. 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
- dejan 6y ago
  Hi, dejan from Migadu here. Thank you for your comment. We are happy to correct ourselves, but your comment does not prove us wrong to the reader. 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 :)
  - detaro 6y ago
    To quote your other comment: > [...] 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.
    - 6y ago
dejan 6y ago
That's a bad title, 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.

33 points by capableweb 6y ago

> at rest 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.

chongli 6y ago
But you can? Just scan and process before encrypting. 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.
- JshWright 6y ago
  End-to-end encryption and encryption at rest are two very different things.
  - jb_gericke 6y ago
    Not clear if the author is referring specifically to mail services like gmail here. Full disk encryption would indeed encrypt my email at rest (assuming I'm syncing mail locally on my laptop with FDS turned on).
jcims 6y ago
The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA: >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.
- Jon_Lowtek 6y ago
  yeah that gets clear when they talk about their certified physical security: there is a strong assumption that drives can not be stolen and will be destroyed at their EOL. Such assumptions often don't hold. Encryption and physical protection are not redundant, they are defense in depth. 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.
  - PeterisP 6y ago
    In addition to protecting against losing hard drives, 'encryption at rest' (as applied in e.g. card industry) can also protect the data from an attacker who gets full access to the database through e.g. a SQL injection, if properly implemented.
- matheusmoreira 6y ago
  > please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself 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.
  - Jon_Lowtek 6y ago
Cantbekhan 6y ago
Couldn't the indexing issue be solved by only having the client/user do the indexing while e-mails are stored encrypted on the server? Ideally on an encrypted device which will keep/maintain the indexing. 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.

Simulacra 6y ago

Email can certainly be encrypted at rest, server or client side, maybe not as quickly or with little resources, but it can be encrypted.

asdjklqwwq 6y ago

About 2FA. Protomail does have it, by having their own proxy app on client's side. Your mail apps do not connect to mail server directly, instead, they connect to the proxy app, and proxy app is authed with 2FA.

skoll43 6y ago

whats the problem with GnuPG and mailvelope ?

Jon_Lowtek 6y ago
none - but they are not "encryption at rest by the mail server provider" which is what the article is about

niftylettuce 6y ago

If you just need email forwarding with a custom domain: https://forwardemail.net https://forwardemail.net (creator here)

deleted 6y ago

[deleted]

dane-pgp 6y ago

> 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. 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]. [0] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [1] https://github.com/w3c-ccg/hashlink https://github.com/w3c-ccg/hashlink

1970-01-01 6y ago

False!

Ayesh 6y ago

This article is brutally honest. It's the first time I see their service, and they sure offer an honest service with no BS.

compsciphd 6y ago

paper I had an idea for that was mostly done by an undergrad (now a professor) https://www.acsac.org/2007/papers/161.pdf 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. ---

dejan 6y ago
Thank you for posting this. Interesting! But in this case, if user were to forget password, the data would be lost, would it not?
- compsciphd 6y ago
  I mean, if I ran my own server and forgot the password to it, the data could be lost as well....

jiveturkey 6y ago

> We refuse to sell quackery. 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

dejan 6y ago
Hi, dejan from Migadu here. Thank you for your comment. We are happy to correct ourselves, but your comment does not prove us wrong to the reader. 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 :)
- detaro 6y ago
  To quote your other comment: > [...] 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.
  - 6y ago

dejan 6y ago

That's a bad title, 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.