[Dovecot] Pointers for developing a proper encryption plugin?
Hi all,
One thing that's always itching when I think about mail-servers, is the storage of e-mail messages in (rather) plain-text. Meaning, any administrator with sufficient privileges would be able to read messages not meant for them. Of course, PGP alike solutions exist, but that's not for the masses.
In my opinion I would like to have e-mail messages stored encrypted using a (strong) user-supplied password. That password would ideally be the same as the one the user logs in with. So for me it's okay to place and enforce that requirement on any of the users.
Having this in place would for sure reassure external auditors/accountants of any kind.
Having Google'd from here to 'yonder and consulting experts on Experts Exhange, I have come up with only this pointer: http://dovecot.markmail.org/search/?q=dovecot+encrypt#query:dovecot%20encryp... It mention the same issue, and also mentions the non-existence of a solution (back in May 2010). But, beforing diving into developing solutions myself, I have to be absolutely sure that there isn't any solution yet. And, in consequence of non-existence: what would allow me to fasttrack any development efforts on this? Is there an overview available where I could learn the best approach for plugin development? Tutorials maybe?
Kind regards, Jeroen Zuijderhoudt.
On Jan 3, 2011, at 10:05 AM, dovecot@moorooboorai.com wrote:
Hi all,
One thing that's always itching when I think about mail-servers, is
the storage of e-mail messages in (rather) plain-text. Meaning, any administrator with sufficient privileges would be able
to read messages not meant for them. Of course, PGP alike solutions exist, but that's not for the masses.In my opinion I would like to have e-mail messages stored encrypted
using a (strong) user-supplied password. That password would ideally be the same as the one the user logs in
with. So for me it's okay to place and enforce that requirement on any of
the users.
Would forgotten passwords result in lost emails?
// Brad
To store the messages safely/safeish, I think you will have to use public key cypto. Messages delivered should be encrypted with the user's public key on delivery, and decrypted by combination of the user's server side stored secret key and login passphrase. The secret key probably also would need to be stored somewhere serverside "in escrow" -- in case the user forgets his passphrase.
"any administrator with sufficient privileges" will still be able to sniff the password and decrypt the messages... but that's probably unavoidable unless you use full end to end encryption a-la PGP/GPG, S/MIME, ..
-jf
On 3.1.2011, at 20.49, Bradley Giesbrecht wrote:
One thing that's always itching when I think about mail-servers, is the storage of e-mail messages in (rather) plain-text. Meaning, any administrator with sufficient privileges would be able to read messages not meant for them. Of course, PGP alike solutions exist, but that's not for the masses.
In my opinion I would like to have e-mail messages stored encrypted using a (strong) user-supplied password. That password would ideally be the same as the one the user logs in with. So for me it's okay to place and enforce that requirement on any of the users.
Would forgotten passwords result in lost emails?
If the mails are encrypted with PGP, then..
a) yeah, if you lost your private key or its password, they're lost
b) but you can change the private key's password
c) and you could also sign the messages with a 3rd admin-key and admin would be able to decrypt them, but this would make it all pretty much pointless.
Am 04.01.2011 00:58, schrieb Timo Sirainen:
a) yeah, if you lost your private key or its password, they're lost
If users are aware of that, that will be ok.
b) but you can change the private key's password
private key should be encrypted with users password. A "change password" tool must change passphrase for users private key.
c) and you could also sign the messages with a 3rd admin-key and admin would be able to decrypt them, but this would make it all pretty much pointless.
This may be desirable in enterprise environments, but not for public mail services. Admin shoud decide to do so or nor.
Christian
On 3.1.2011, at 20.05, dovecot@moorooboorai.com wrote:
One thing that's always itching when I think about mail-servers, is the storage of e-mail messages in (rather) plain-text. Meaning, any administrator with sufficient privileges would be able to read messages not meant for them. Of course, PGP alike solutions exist, but that's not for the masses.
In my opinion I would like to have e-mail messages stored encrypted using a (strong) user-supplied password. That password would ideally be the same as the one the user logs in with. So for me it's okay to place and enforce that requirement on any of the users.
See http://dovecot.org/patches/2.0/mail-filter.tar.gz - you should be able to use that to pass all emails to a filter that decrypts mails. I'm not happy that imap process there forks new processes, it should be more like quota-warning where dovecot master process forks them. So it'll probably change.
I remember Alex Baule has been talking about things more or less related to this.. Although I'm not longer entirely certain what it is that he's built. You could try asking him.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jan 04, 2011 at 01:53:37AM +0200, Timo Sirainen wrote:
On 3.1.2011, at 20.05, dovecot@moorooboorai.com wrote:
One thing that's always itching when I think about mail-servers, is the storage of e-mail messages in (rather) plain-text.
[...]
- I remember Alex Baule has been talking about things more or less related to this.. Although I'm not longer entirely certain what it is that he's built. You could try asking him.
Imho, once messages are decrypted/decryptable server-side (be it password, key whatever) we've lost. Messages have to be decrypted client-side.
The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go.
A nice challenge would be to devise something to do full-text indexing on the server-side encrypted data (it won't be as efficient as indexing of plain text, but... is that at all possible?)
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFNIsBRBcgs9XrR2kYRAg0WAJ9aI2hFWYyvcZmWiEYHwwyLADZl8wCfUtqN YWl/Wp5Ff3iFBE0/0pypqkA= =3Waa -----END PGP SIGNATURE-----
Am 04.01.2011 07:38, schrieb tomas@tuxteam.de:
The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go.
I would support that idea. Private key should be encrypted with users passphrase. If user changes password privet key needs to be decrypted with old password and reencrypted with new password.
Public key never changes, so maildir is never required to be touched, if user changes password and server does not need to know users secret to receive mail.
I would wish that Timo would consider to implement required functions to plugin API, so such a plugin would be possible without massive patching Dovecot source code.
Christian
On 6.1.2011, at 13.54, Christian Felsing wrote:
I would support that idea. Private key should be encrypted with users passphrase. If user changes password privet key needs to be decrypted with old password and reencrypted with new password.
Public key never changes, so maildir is never required to be touched, if user changes password and server does not need to know users secret to receive mail.
I would wish that Timo would consider to implement required functions to plugin API, so such a plugin would be possible without massive patching Dovecot source code.
It is possible without patching. There is already a plugin that can be used to implement what you want (although it could be slightly improved): http://dovecot.org/patches/2.0/mail-filter.tar.gz
Basically that plugin allows you to call a script when reading a mail. You can have that script call gpg or whatever to decrypt the mail when necessary.
The only small problem is about how to transfer the user's password to the script, but even that wouldn't require more than a couple of lines of new code to the plugin.
- Christian Felsing hostmaster@taunusstein.net:
I would wish that Timo would consider to implement required functions to plugin API, so such a plugin would be possible without massive patching Dovecot source code.
It would come in handy for archiving mail as well!
-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de
On 01/06/2011 06:54 AM, Christian Felsing wrote:
Am 04.01.2011 07:38, schrieb tomas@tuxteam.de:
The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go.
I would support that idea. Private key should be encrypted with users passphrase. If user changes password privet key needs to be decrypted with old password and reencrypted with new password.
Public key never changes, so maildir is never required to be touched, if user changes password and server does not need to know users secret to receive mail.
This still doesn't work, because the administrator is the one who tells the system to encrypt messages as they arrive. He can peek at the messages before they're encrypted with the user's public key.
It's impossible to hide the contents of a plain-text message from the person who receives it in plain text (the administrator). PGP/GPG is the only option.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jan 06, 2011 at 02:05:29PM -0500, Michael Orlitzky wrote:
On 01/06/2011 06:54 AM, Christian Felsing wrote:
Am 04.01.2011 07:38, schrieb tomas@tuxteam.de:
The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go.
[...]
This still doesn't work, because the administrator is the one who tells the system to encrypt messages as they arrive. He can peek at the messages before they're encrypted with the user's public key.
Right. You just reduce the window of opportunity: if a system gets compromised, the attacker can just peek on newly arriving mail, not on already delivered mail.
It's impossible to hide the contents of a plain-text message from the person who receives it in plain text (the administrator). PGP/GPG is the only option.
You mean end-to-end? We are in violent agreement, then. Encryption-on-arrival is just a mitigation technique. Best is to get others to send me encrypted mail.
But the other techniques discussed here (e.g. having a Dovecot plugin decrypt the mails before serving) seem to me nearly useless (at least not worth the bother). Because at some point, this very plugin must have the key available in some unprotected form, and then whoever compromises the server can capture the key. So it wouldn't reduce signifcantly the area of vulnerability.
This all IMO, of course.
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD4DBQFNJsvcBcgs9XrR2kYRAqkyAJ45Fp3H89IpdPPLyetFkRL0bCj/wgCVFCb+ QSFw9PHqZvzgeX9qIqzIsw== =vPsq -----END PGP SIGNATURE-----
On 7.1.2011, at 10.16, tomas@tuxteam.de wrote:
But the other techniques discussed here (e.g. having a Dovecot plugin decrypt the mails before serving) seem to me nearly useless (at least not worth the bother). Because at some point, this very plugin must have the key available in some unprotected form, and then whoever compromises the server can capture the key. So it wouldn't reduce signifcantly the area of vulnerability.
There is also the possibility of doing the decryption on a more trusted Dovecot proxy.
On Thu, Jan 06, 2011 at 02:05:29PM -0500, Michael Orlitzky wrote:
This still doesn't work, because the administrator is the one who tells the system to encrypt messages as they arrive. He can peek at the messages before they're encrypted with the user's public key.
That's a small window of opportunity, compared to letting anyone who has access or can break into the filesystem/backup-system get access to all messages without any further complications.
I.e. currently it takes a "read-any-file" vulnerability (or access) to read all users messages, with server-side encrypted mailfiles it will require "read-any-file" + strace processes while user is active. Then you no longer need to worry about anyone getting access to your backups, read dead/decomissioned drives, sysadmins "accidentally" reading files, etc..
It's impossible to hide the contents of a plain-text message from the person who receives it in plain text (the administrator). PGP/GPG is the only option.
Sure, end to end encrypted messages is the only way to be completely sure they're not read in transit.. But the fact that ~0% of our users send/receive encrypted messages doesn't mean that we should disable SSL for POP/IMAP connections. Sysadmin/network-admins can just read the incoming plain text message anyway, so why use SSL on the last mile ? ;-)
-jf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jan 06, 2011 at 12:54:57PM +0100, Christian Felsing wrote:
Am 04.01.2011 07:38, schrieb tomas@tuxteam.de:
The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go.
I would support that idea. Private key should be encrypted with users passphrase. If user changes password privet key needs to be decrypted with old password and reencrypted with new password.
Hm. I think I didn't express my idea correctly. The decryption has to happen client-side if it has to be any worth, IMO.
Public key never changes, so maildir is never required to be touched, if user changes password and server does not need to know users secret to receive mail.
I would wish that Timo would consider to implement required functions to plugin API, so such a plugin would be possible without massive patching Dovecot source code.
As Timo said downthread, there is already such a plugin, but... this would support decryption server-side (which IMO would be wrong anyway).
For client-side decryption, the infrastructure is (almost) completely there. GPG for the client (and encryption on delivery -- but every delivery agent I know of has some hooks for filtering messages).
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFNJsp2Bcgs9XrR2kYRAg87AJ9K2Aixc6aMozbYvW8BnGL9Tg8vJACfRRVT l2DOhXS6h5QwXxmuJCbjJL8= =k96l -----END PGP SIGNATURE-----
tomas@tuxteam.de wrote:
Hm. I think I didn't express my idea correctly. The decryption has to happen client-side if it has to be any worth, IMO.
As Timo said downthread, there is already such a plugin, but... this would support decryption server-side (which IMO would be wrong anyway).
For client-side decryption, the infrastructure is (almost) completely there. GPG for the client (and encryption on delivery -- but every delivery agent I know of has some hooks for filtering messages).
There is also S/MIME encryption built in to many clients.
participants (9)
-
Bradley Giesbrecht
-
Christian Felsing
-
dovecot＠moorooboorai.com
-
Jan-Frode Myklebust
-
Michael Orlitzky
-
Ralf Hildebrandt
-
Timo Sirainen
-
tomas＠tuxteam.de
-
Willie Gillespie