Quoting Miquel van Smoorenburg <miqu...@cistron.nl>:
On 28/10/13 23:22, Frerich Raabe wrote:
On 2013-10-28 20:23, Reindl Harald wrote:
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
However, it would be nice to know that even if we were breached, the
emails on the server were encrypted and would be completely useless
to an attacker.
This type of encryption is ideal and some regulations prefer
(although don't require) it
impossible and useless
if someone comes that far he can also read whatever configuration
containing the keys
In principle, this can be addressed by employing asymmetric key
encryption.
You could imagine a system which requires users to generate a key pair
and then submit their public key. The mail system will encrypt all mail
received for a user with that users public key. When accessing the mail,
the user configures his user agent to use the private key to decrypt the
mail.
In practice, it's probably not that easy:
1. I suppose you'd have to be careful to not break features like
server-side searching though. If you only store encrypted mail, the only
moment where the system sees the plain mail is when it's received. So
you'd probably need to index it at that point and then use that index
for subsequent queries. Once the mail is written to disk, the server
never sees the real data anymore.
2. Different mail storage formats probably work differently well. mbox
is right out, with Maildir it might not be acceptable to encode the raw
mail file - I don't know whether Dovecot uses any actual contents of
files with Maildir (as opposed to the Dovecot-specific indices and the
file name). If it does, then you should maybe just encrypt just the body
but no headers or similiar.
There's surely more to consider, but I think this is anything but
"impossible and useless". Accessing sensitive data which is stored on an
untrusted system is an old and solved problem, I wouldn't be surprised
if you just have to consider implementation details in the case of a
mail server.
Well you can generate the public and private key on the server, then set
the users password as the keyphrase, and leave it stored on the server.
Incoming mail would be automatically encrypted with the public key, then
stored.
When the user logs in to imap/pop the password is not only used for
authentication, but also to unlock the private key. Dovecot can then
decrypt the messages on the fly.
Basically this is how Lavamail worked. It is reasonably secure, but
doesn't help against a hostile root user on the server that hacks
dovecot to just log the password when a user logs in. Or someone who has
acquired your SSL keys and taps your internet connection.
Mike.
Or someone that has your email password. Basically, it's no different than
unencrypted mail on an encrypted filesystem.
Doing more work != more secure - that's why Lavamail was nothing more than
a marketing ploy.
Imagine going to your bank to put things in your lockbox, and giving your
personal items to the teller who then runs an obstacle course before
getting to the vault. Are your things more secure than you putting the
items in the lockbox you have the key for?
Use GPG, and make sure the user understands that full text search is not
available. For the client, either they run it locally, use the gpg Chrome
plug-in, or the site implements opengpg.js. Then all decryption occurs
client-side.
http://openpgpjs.org/
You could come up with some custom public/private key exchange, but why?
If you're going to encrypt and decrypt it locally anyways, what does it
matter? The equivalent to the Lavabit hack, without the pointless
runaround, would be to use the Dovecot zip module to encrypt the data so
only the Dovecot process can read it - though you could still trivially log
the user's password for direct data access. IMHO, logging a password you
receive in plain text is far from a hack. To me a hack requires a little
complexity or inginuity.
Rick
