[Dovecot] E-Mail Encryption
Frank Leonhardt
t200907 at fjl.co.uk
Sun Jul 19 17:48:25 EEST 2009
From: tomas at 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
More information about the dovecot
mailing list