[Dovecot] E-Mail Encryption
Hello,
I am new to Dovecot but installation was quite easy, so there is one more LDAP authenticated, Dovecot / Postfix mailbox online, but there is one question left:
I would like to set up a configuration, which encrypts every user mail with a unique key. If user logs in, private key should be decrypted with user password and every mail user requests should be decrypted with users private key. If a mail comes in, it should be encrypted with users public key. That key pair should be used for that purpose only. Obviously a GnuPG plugin between deliver and rest of Dovecot is needed.
best reagrds Christian
On Wed, 2009-07-15 at 18:26 +0200, Christian Felsing wrote:
I would like to set up a configuration, which encrypts every user mail with a unique key. If user logs in, private key should be decrypted with user password and every mail user requests should be decrypted with users private key. If a mail comes in, it should be encrypted with users public key. That key pair should be used for that purpose only. Obviously a GnuPG plugin between deliver and rest of Dovecot is needed.
Feel free to write such a plugin. :) Decryption could be done the same way as zlib plugin works. Encryption would need a bit more work.
So I have to inspect zlib plugin (and Dovecot) code ;-) If plugin "knows" username, it needs a way to get user password in clear text and of course his username to find and decrypt users private key. These items have to be saved in a secure way, while user is logged in. Obviously there are several differences to zlib plugin. If plugin API supports these extra requirements, it should be possible to write such a plugin which will stay compatible to future Dovecot versions.
Encryption should be done in deliver tool, so there is no requirement to touch MTA (e.g. Postfix) code. Deliver tool must know dest. mail adress, so it can ask LDAP for the right public key. Does deliver also support plugins ?
Christian
Timo Sirainen schrieb:
Feel free to write such a plugin. :) Decryption could be done the same way as zlib plugin works. Encryption would need a bit more work.
On Wed, 2009-07-15 at 21:42 +0200, Christian Felsing wrote:
So I have to inspect zlib plugin (and Dovecot) code ;-) If plugin "knows" username, it needs a way to get user password in clear text and of course his username to find and decrypt users private key.
Username is known. There are several ways to get it, but with v1.2 easiest is just getenv("USER"). To get the password you'll need to configure your passdb and userdb specially, but it's possible (as long as user logged in using plaintext authentication).
These items have to be saved in a secure way, while user is logged in.
They'll be in environment variables.
Obviously there are several differences to zlib plugin. If plugin API supports these extra requirements, it should be possible to write such a plugin which will stay compatible to future Dovecot versions.
Plugins can do pretty much anything.
Encryption should be done in deliver tool, so there is no requirement to touch MTA (e.g. Postfix) code. Deliver tool must know dest. mail adress,
Destination mail address would be the same as the username, still in getenv("USER").
so it can ask LDAP for the right public key. Does deliver also support plugins ?
Yes. You'll need to hook into mail-storage API's mailbox_save_*() and mail_get_stream() functions. zlib plugin shows how to hook into mail_get_stream(). For saving .. I just described it recently on this list: http://www.dovecot.org/list/dovecot/2009-June/040181.html
Hello,
I am new to Dovecot but installation was quite easy, so there is one more LDAP authenticated, Dovecot / Postfix mailbox online, but there is one question left:
I would like to set up a configuration, which encrypts every user mail with a unique key. If user logs in, private key should be decrypted with user password and every mail user requests should be decrypted with users private key. If a mail comes in, it should be encrypted with users public key. That key pair should be used for that purpose only. Obviously a GnuPG plugin between deliver and rest of Dovecot is needed.
best reagrds Christian i might fail but this is not the job for an imap server what you need is a gpg gateway mailserver
Christian Felsing schrieb: the only open source i found is here http://www.djigzo.com/
comercial http://www.zertificon.com/
if there are other solutions , i will be happy to hear about it
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
The only benefit this would being, is email being saved on the server
would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails,
but then, he can just as easily read them as they come in or out of
the system.
Quoting Christian Felsing <hostmaster@taunusstein.net>:
Hello,
I am new to Dovecot but installation was quite easy, so there is one more LDAP authenticated, Dovecot / Postfix mailbox online, but there is one question left:
I would like to set up a configuration, which encrypts every user mail with a unique key. If user logs in, private key should be decrypted with user password and every mail user requests should be decrypted with users private key. If a mail comes in, it should be encrypted with users public key. That key pair should be used for that purpose only. Obviously a GnuPG plugin between deliver and rest of Dovecot is needed.
best reagrds Christian
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system.
Actually such encryption is interesting as a protection in case when someone steals server hardware/disks.
-- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/
Arkadiusz Miskiewicz wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system.
Actually such encryption is interesting as a protection in case when someone steals server hardware/disks.
It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :)
Cheers, Thomas
Thomas schreef:
Arkadiusz Miskiewicz wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system.
Actually such encryption is interesting as a protection in case when someone steals server hardware/disks.
It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :)
Cheers, Thomas
When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic...
The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:)
-- Tom
Tom Hendrikx wrote:
Thomas schreef:
Arkadiusz Miskiewicz wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system. Actually such encryption is interesting as a protection in case when someone steals server hardware/disks. It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :)
Cheers, Thomas
When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic...
The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:)
Encrypting with a public key is completely reasonable, but for proper security, the decryption should only take place on the client's trusted workstation with their private key.
~Seth
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jul 16, 2009 at 12:51:32AM -0700, Seth Mattinen wrote:
[...]
Encrypting with a public key is completely reasonable, but for proper security, the decryption should only take place on the client's trusted workstation with their private key.
Hear, hear!
Let me state it again: nothing is gained with server-side *de*cryption which can't be achieved more easily with disk encryption. Werver-side encryption is another thing...
Yes, Seth, I'm just paraphrasing you, but this is so important (and often forgotten) that it cannot be over-emphasised.
And the infrastructure for that is already there: gpg-encrypt every mail on delivery with the users public key. The user's MUA should take care of the rest.
Alas, (server-side) full text search goes out of the window with that (unless there is a clever scheme to do some indexing without giving away too much info, but there I reached the limit of my knowledge :)
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKXvyMBcgs9XrR2kYRAijYAJ4nIteX/70MmvpEIeHILbqNictHjACeLAv+ xzTTkbTbhGUdG9HYDItXioI= =JstP -----END PGP SIGNATURE-----
tomas@tuxteam.de wrote:
Let me state it again: nothing is gained with server-side *de*cryption which can't be achieved more easily with disk encryption. Werver-side encryption is another thing...
One use case is where you have regulatory or policy determination that certain email should be unreadable even to certain groups of users who have elevated access to the server.
Obviously you need to beware network sniffers on the inbound side, but take a look at MSExchange to see how they fairly cunningly encrypt in such a way that you can grant certain users rights to see certain mailboxes and encryption is used to make sure that permission is fairly thoroughly enforced.
The main purpose is that you really want to minimise the backdoor where the IT admins have access to potentially sensitive emails from management/traders/corporate finance/legal, etc in large organisations
Sure it's hard to totally eliminate the ability for the IT guys to get up to no good, but as far as possible things need to be locked down and a granular encryption solution is the main way to tackle that. (But whole disk encryption is at least a good start).
Complete end to end encryption is a cunning idea and of course the only way to be sure there are no man in the middle attacks, but of course this breaks all server based content filtering and virus scanning, so it's unpopular right now... Most solutions need to involve a trusted server application sitting in the middle
WOuld be extremely interested to hear from anyone using Dovecot in some kind of "big biz" environment and how they tackle various policy issues like this?
Cheers
Ed W
On Thu, 16 Jul 2009, Tom Hendrikx wrote:
Thomas schreef:
Arkadiusz Miskiewicz wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection. Actually such encryption is interesting as a protection in case when someone steals server hardware/disks. It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :)
If someone manages to steal hardware, there nothing would stop such person from simply starting the system. And since system will rather start up automatically, the disk(s) would be decrypted. Correct me if I'm wrong.
When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic...
But it would be a great option for maintaining a mail system for any corporation - usually management-level users are paranoid about someone reading their emails... The only problem is, that in such situation passwords should not be stored in plaintext...
The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:)
As I say - hard disk encryption does not solve problem when someone steals the hardware, does not help when your clients are paranoid :)
Best regards,
Jacek Osiecki joshua@ceti.pl GG:3828944 I don't want something I need. I want something I want.
Some companies and governments in the United States at least have very strict policy requirements regarding various aspects of security and encryption. Transit encryption (ssl/tls from MTA to MTA) and local encryption of messages sometimes is a requirement if you want to be able to bid on government contracts.
https://www.bidsync.com/DPX?ac=view&auc=158380 This example is not for hosting mail but for an anti-spam/anti-virus service (they refer to it as email hygiene) that required message encryption on the transit MTA servers disk as well as tls/ssl for MTA to MTA encryption.
So this example does not apply directly to Dovecot but it does show there are needs for this level of encryption in general for various customers.
-----Original Message----- From: dovecot-bounces+jkrejci=usinternet.com@dovecot.org [mailto:dovecot-bounces+jkrejci=usinternet.com@dovecot.org] On Behalf Of Tom Hendrikx Sent: Thursday, July 16, 2009 2:47 AM To: Thomas Cc: dovecot@dovecot.org Subject: Re: [Dovecot] E-Mail Encryption
Thomas schreef:
Arkadiusz Miskiewicz wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system.
Actually such encryption is interesting as a protection in case when someone steals server hardware/disks.
It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :)
Cheers, Thomas
When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic...
The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:)
-- Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jul 16, 2009 at 09:36:30AM -0500, Justin Krejci wrote:
Some companies and governments in the United States at least have very strict policy requirements regarding various aspects of security and encryption.
Understandable.
Transit encryption (ssl/tls from MTA to MTA)
This makes sense, since one might assume the channel to be less secure than the endpoints. Note though that the most important part is the _authentication_ part, and this encompasses things like a key distribution ifrastructure (à la PKI or some such). And this is the juicy part.
and localencryption of messages
We do agree that local encryption of messages is a Good Thing. But just like that, without context, this phrase just amounts to Marketing Oriented Hand Wawing, sorry. The meat of the discussion (and what was being talked about in this thread is:
where do you decrypt? (1)Server-side? (1.1) Only on the "running" server? (nearly equivalent to this would be to have a permanent key storage on the server, but suitably armored by passphrase). (1.2) On the "quiescent" server? (2)client-side?
Now it all amounts to the threat models you want to protect against.
(1.2) just protects you against very little. Whoever "gets" the server (dead or alive) gets the decryption key. You've lost. And if your server is sufficiently protected, you just don't need encryption.
(1.1) would protect yoou against someone "getting" the "dead" server (e.g. by stealing its disk). Just the same as encrypting the whole disk (assuming the unlock passprhase isn't stored near the server). Encrypting the whole disk has even the advantage that your swap space will be encrypted, which protects you against key bits hitting swap (by some dumb bug in key management software -- this has definitely happened!).
This option doen't offer any relief if someone hi-jacks the
"live" server (trojan or similar).
So For this threat model (no hi-jacking, just loss of hardware)
I'd definitely go for whole-disk encryption. That's what I do
with my laptops.(2) This is actually the best solution. It won't protect you against the client being hi-jacked or stolen, but all other schemes above are vulnerable against that.
Did I forget anything?
Corollary: Decrypting data server-side buys you (nearly) nothing compared to whole-disk encryption server side.
sometimes is a requirement if you want to be able tobid on government contracts.
Sorry, I didn't understand the page you linked to.
This example is not for hosting mail but for an anti-spam/anti-virus service (they refer to it as email hygiene) that required message encryption on the transit MTA servers disk as well as tls/ssl for MTA to MTA encryption.
Sorry. "required message encryption on the transit MTA" is just this kind of handwaving: to decide whether this is useful or Just Another Checkbox For Marketing (TM), you'd have to specify more (at least *who will be able to decrypt that stuff*).
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKYEMnBcgs9XrR2kYRAilcAJ97p36ZpQzBJuDp6zwSwjoWLOgBlwCcCnAJ bQH1pfumJel/WtEVDAFuGEo= =1MRQ -----END PGP SIGNATURE-----
I've thought that it would be nice if my mail was always converted to OpenPGP encrypted form.
My setup is, I use fetchmail to pull in my mail to dovecot. Then I read it using kmail (which supports OpenPGP as well as S/MIME).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Jul 17, 2009 at 08:04:24AM -0400, Neal Becker wrote:
I've thought that it would be nice if my mail was always converted to OpenPGP encrypted form.
My setup is, I use fetchmail to pull in my mail to dovecot. Then I read it using kmail (which supports OpenPGP as well as S/MIME).
Yes, that would be basically my preferred setup.
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKYHMzBcgs9XrR2kYRArzdAJ9sEYh8cpJDfB6ZcyybjjkyLYZzOwCeICkH cIEkNwQB5uhueDjUTmRe8iA= =YW4S -----END PGP SIGNATURE-----
From: tomas@tuxteam.de
We do agree that local encryption of messages is a Good Thing. But just like that, without context, this phrase just amounts to Marketing Oriented Hand Wawing, sorry. The meat of the discussion (and what was being talked about in this thread is:
where do you decrypt? (1)Server-side? (1.1) Only on the "running" server? (nearly equivalent to this would be to have a permanent key storage on the server, but suitably armored by passphrase). (1.2) On the "quiescent" server? (2)client-side?
Now it all amounts to the threat models you want to protect against.
(1.2) just protects you against very little. Whoever "gets" the server (dead or alive) gets the decryption key. You've lost. And if your server is sufficiently protected, you just don't need encryption.
(1.1) would protect yoou against someone "getting" the "dead" server (e.g. by stealing its disk). Just the same as encrypting the whole disk (assuming the unlock passprhase isn't stored near the server). Encrypting the whole disk has even the advantage that your swap space will be encrypted, which protects you against key bits hitting swap (by some dumb bug in key management software -- this has definitely happened!).
This option doen't offer any relief if someone hi-jacks the "live" server (trojan or similar). So For this threat model (no hi-jacking, just loss of hardware) I'd definitely go for whole-disk encryption. That's what I do with my laptops.(2) This is actually the best solution. It won't protect you against the client being hi-jacked or stolen, but all other schemes above are vulnerable against that.
Did I forget anything?
I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server. This, of course, depends a lot on the environment its running in so everyone's experience is going to differ.
Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on the door. I'm not too worried about them.
What experience has shown me is that there's a good chance that a running server will compromised eventually. If you think your software locks are good enough it probably means you haven't been around long enough. Remember Qpopper? No? 'nuff said.
A quick reminder - the risk level is the product of the probability and the severity of an event occuring. The probability can be a lot less than unity when the severity relates to the theft of everyone email (including passwords, CC details &c) - not to mention the embarrassment factor.
So, encrypting the mail file makes a lot of sense. If it's done properly (not always a given). No alien process could read the mail, even if it had access to the file itself. Depending on the 'whole disk' encryption scheme used, if the attacker had root access there'd be no protection whatsoever. It's long been a rule-of-thumb to assume that the root password is compromised in any security scenario.
Part of the definition of 'done properly' above is NOT placing the decryption keys in backing store.
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Another advantage of doing your own encryption is the possibility of only encrypting the message bodies. Having the message headers in clear text has obvious advantages. I'm sure we're all used to skipping through mail files to find out what's gone wrong - you never want to read the message anyway.
Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place.
Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem!
Regards, Frank
On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt (t200907@fjl.co.uk) wrote:
Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on the door. I'm not too worried about them.
How much good do your locks do when police comes and wants to confiscate your servers because they suspect one of your users has done something criminal? Do you trust they take as good care of the machines as you do?
What experience has shown me is that there's a good chance that a running server will compromised eventually.
Agreed on that.
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Some people favour it for the very same reasons...
Another advantage of doing your own encryption is the possibility of only encrypting the message bodies. Having the message headers in clear text has obvious advantages. I'm sure we're all used to skipping through mail files to find out what's gone wrong - you never want to read the message anyway.
Agreed again.
Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place.
Here I beg to differ. You are right in the simple situation where there's just one admin who's a crook to begin with, but often enough there're several and only one (or few) unreliable ones among them, and even if they're all good they can be forced by their bosses or blackmailers or even untrustworthy authorities. This is not purely theoretical, I can assure you.
Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem!
I think the far majority of cases are like that, and I'd guess most dovecot admins wouldn't bother with encryption even if it were available. But for some it would be a real boon.
-- Tapani Tarvainen
On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt (t200907@fjl.co.uk) wrote:
Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on
On 19/07/2009 16:03, Tapani Tarvainen wrote: the
door. I'm not too worried about them.
How much good do your locks do when police comes and wants to confiscate your servers because they suspect one of your users has done something criminal? Do you trust they take as good care of the machines as you do?
How do you know I'm *not* the Police?
We're in very interesting territory here, and it's going to depend on your local laws. In England the police are pretty okay about things, and are glad to have you extract the data yourself. If they really want to do it themselves it's easy enough to give them half a mirror.
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Some people favour it for the very same reasons...
Again, it depends on the jurisdiction. In England, if you can't decrypt the data it can be a bit awkward (RIPA) - unless it's clearly NOT your data in the first place (i.e. a message body).
Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place.
Here I beg to differ. You are right in the simple situation where there's just one admin who's a crook to begin with, but often enough there're several and only one (or few) unreliable ones among them, and even if they're all good they can be forced by their bosses or blackmailers or even untrustworthy authorities. This is not purely theoretical, I can assure you.
Yes, but the rogue administrator ought to be able to circumvent encryption anyway - if it's whole disk it's effectively not encrypted. It'd rely on a policy of someone else periodically checking the files to see if they were still encrypted - don't see that happening somehow! And even then, an administrator could easily tee the data off before its stored.
The main reason I'd be in favour of application-based file encryption is to get around the fact that whole-disk encryption is meaningless as protection from the operator - if the operator is dodgy (or someone's bypassed security) then they can read the mail files just as easily as everything else. If the files themselves are encrypted then access to the running system won't reveal their contents (although it would help).
On Fri, Jul 24, 2009 at 09:39:25PM +0100, Frank Leonhardt (t200907@fjl.co.uk) wrote:
How much good do your locks do when police comes and wants to confiscate your servers because they suspect one of your users has done something criminal? Do you trust they take as good care of the machines as you do?
How do you know I'm *not* the Police?
I don't. But I do know dovecot is being used by people who are not, and probably also some who have a reason to distrust the police.
We're in very interesting territory here, and it's going to depend on your local laws. In England the police are pretty okay
Sure. Ditto in Finland. But not everywhere.
In England, if you can't decrypt the data it can be a bit awkward (RIPA)
In some places it could save many people from torture and death. (There are situations where the *good* option is having just yourself tortured to death because you *can't* decrypt the data.)
OK, that's a bit extreme, but it's not hard to imagine more common scenarios where being able to just delay the decryption could be useful.
[...] the rogue administrator ought to be able to circumvent encryption anyway - if it's whole disk it's effectively not encrypted.
Whole-disk encryption is ineffective against rogue admins, yes - only application-level encryption (decrypting in client) helps there. But whole-disk encryption is useful against untrustworthy police and burglars, even when application encryption is also being used in the way being discussed, where only message content is encrypted: logs and header information and the like can be critical, too.
The main reason I'd be in favour of application-based file encryption is to get around the fact that whole-disk encryption is meaningless as protection from the operator - if the operator is dodgy (or someone's bypassed security) then they can read the mail files just as easily as everything else. If the files themselves are encrypted then access to the running system won't reveal their contents (although it would help).
I'm in favour of both whole-disk and application-based encryption. They complement each other, neither makes the other useless.
-- Tapani Tarvainen
On 25/07/2009 10:37, Tapani Tarvainen wrote:
On Fri, Jul 24, 2009 at 09:39:25PM +0100, Frank Leonhardt (t200907@fjl.co.uk) wrote:
How much good do your locks do when police comes and wants to confiscate your servers because they suspect one of your users has done something criminal? Do you trust they take as good care of the machines as you do? How do you know I'm *not* the Police?
I don't. But I do know dovecot is being used by people who are not, and probably also some who have a reason to distrust the police.
We're in very interesting territory here, and it's going to depend on your local laws. In England the police are pretty okay
Sure. Ditto in Finland. But not everywhere.
<SNIP>
I think we can all agree on that. However, in practical terms it's better if the email users encrypt their own mail and keep the ISP out of it. If the mail user is a friend then they're putting you in a difficult situation (you get tortured instead of them....). If if your a big ISP (e.g. Yahoo) then commercial considerations mean you don't care anyway.
The main reason I'd be in favour of application-based file encryption is to get around the fact that whole-disk encryption is meaningless as protection from the operator - if the operator is dodgy (or someone's bypassed security) then they can read the mail files just as easily as everything else. If the files themselves are encrypted then access to the running system won't reveal their contents (although it would help).
I'm in favour of both whole-disk and application-based encryption. They complement each other, neither makes the other useless.
Agreed again - my argument was that application-specific encryption was useful regardless of whole-disk (and in my scenario, whole-disk isn't much use as the hardware's secure).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt wrote:
From: tomas@tuxteam.de
We do agree that local encryption of messages is a Good Thing [...]
Did I forget anything?
I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server.
I don't think we differ that much. For your typical "web server out there" I think there is a non-negligible risk of it being hacked (I think that is your assessment too). That means: plan for that eventuality. Don't keep things on this machine if you don't have to.
Or did I get you wrong?
[elided part: agree wholeheartedly]
So, encrypting the mail file makes a lot of sense [...]
That's why I always talk about *de*crypting. I'm all for encrypting on the server (agreed, the server "sees" the clear-text files at some point in time, but once they are encrypted and all the remnants out of swap, we are safe). What I don't see as an advance (wrt whole-disk encryption) is when it's possible to *de*crypt the sensitive data on the server.
[...]
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Agreed on recovery. Not so much on forensics (you'd have to have the key, but I'd see that as a Good Thing).
[...]
Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem!
Fully agreed, but one would have to entice people to send encrypted mail all the time. How would you go about that?
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKZCyYBcgs9XrR2kYRApKgAJ9UrFBe8VtJJP/3a/nC6m+USD65pgCeMqrS V8IBFpcqiSs0kl+LCrf2bz0= =SofB -----END PGP SIGNATURE-----
On 20/07/2009 09:36, tomas@tuxteam.de wrote:
On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt wrote:
From: tomas@tuxteam.de
We do agree that local encryption of messages is a Good Thing [...]
Did I forget anything? I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server.
I don't think we differ that much. For your typical "web server out there" I think there is a non-negligible risk of it being hacked (I think that is your assessment too). That means: plan for that eventuality. Don't keep things on this machine if you don't have to.
Or did I get you wrong?
No - I probably got you wrong!
[elided part: agree wholeheartedly]
So, encrypting the mail file makes a lot of sense [...]
That's why I always talk about *de*crypting. I'm all for encrypting on the server (agreed, the server "sees" the clear-text files at some point in time, but once they are encrypted and all the remnants out of swap, we are safe). What I don't see as an advance (wrt whole-disk encryption) is when it's possible to *de*crypt the sensitive data on the server.
Definitely.
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Agreed on recovery. Not so much on forensics (you'd have to have the key, but I'd see that as a Good Thing).
It get's messy. Withholding keys puts you (as the owner of the server) in a very tricky situation. Better to leave it to the users - if they encrypt the data then it's not your problem.
Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem!
Fully agreed, but one would have to entice people to send encrypted mail all the time. How would you go about that?
I find that spending lots of money on their credit card gets the message across :-)
On Thu, Jul 16, 2009 at 09:06:19AM +0200, Arkadiusz Miskiewicz (arekm@maven.pl) wrote:
On Wednesday 15 of July 2009, Patrick Domack wrote:
The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection.
I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system.
Actually such encryption is interesting as a protection in case when someone steals server hardware/disks.
Or when the regular, trustworthy sysadmin is temporarily replaced by a crook or is blackmailed or is overridden by a pointy-haired boss. Indeed it might be valuable protection for the sysadmin who doesn't want to compromise other people's mail: no need to refuse orders when you *can't* read them. (New mails can of course still be intercepted as noted, but that doesn't mean protecting old stuff isn't useful.)
Anyway, this can be done with procmail as well, but a dovecot plugin might be more convenient.
-- Tapani Tarvainen
participants (15)
-
Arkadiusz Miskiewicz
-
Christian Felsing
-
Ed W
-
Frank Leonhardt
-
Jacek Osiecki
-
Justin Krejci
-
Neal Becker
-
Patrick Domack
-
Robert Schetterer
-
Seth Mattinen
-
Tapani Tarvainen
-
Thomas
-
Timo Sirainen
-
Tom Hendrikx
-
tomas＠tuxteam.de