Re: [Dovecot] Encryption solution for messages at rest

[Marc Perkel]

On 10/28/2013 9:02 AM, Douglas Mortensen wrote:

Hi,

We have clients with various security & compliance requirements. Although not 
required, it would be ideal to have messages encrypted at rest. We already use 
SSL/TLS to secure the transmission of most email. However, it would be nice to have 
them encrypted sitting on our server. Is anyone doing this? I think that ideally, 
rather than full-disk encryption, we should use an encryption that encrypts the 
actual email messages as they sit on our file system. This way even if we ever had 
our server breached by an attacker, they wouldn't be able to do anything with the 
messages. However, this would also mean that if the attacker can't decrypt the 
files, than dovecot and postfix still would need to. This means that the encryption 
key would need to be available to the dovecot deamon. We'd either need to have it 
in a file that is restricted to access only by dovecot (less secure), or use an 
encryption passphrase for the certificate which would have to be typed in manually 
each time that dovecot starts or restarts (more secure, but also more work and 
possibility of disruption because the server can't restart gracefully without a 
human being having to be present [although I don't think we have issues with 
unexpected restarts anyway]).

Is anyone doing anything like this with dovecot?

Thanks!!
-
Doug Mortensen
Network Consultant
Impala Networks Inc
CCNA, MCSA, Security+, A+
Linux+, Network+, Server+
A.A.S. Information Technology
.
www.impalanetworks.com
P: (505) 327-7300
F: (505) 327-7545



I use OpenVZ which is a near 0 overhead virtualization for Linux only. 
So I create a separate virtual machine for web services and email 
services. So someone hacking the web will never get at the email because 
it's not there. It also allows me to back them up separately and 
move/restore them separately on different computers.

Re: [Dovecot] Encryption solution for messages at rest

[Rick Romero]

 Quoting Miquel van Smoorenburg :


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

Re: [Dovecot] Encryption solution for messages at rest

[Reindl Harald]

Am 30.10.2013 15:54, schrieb Michael Orlitzky:
> On 10/30/2013 09:01 AM, Benny Pedersen wrote:
>> Michael Orlitzky skrev den 2013-10-28 20:49:
>>
>>>   php_admin_value open_basedir /var/www/$domain/$host/
>>>   php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
>>>   php_admin_value session.save_path /var/www/$domain/$host/tmp
>>>   php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
>>
>> so dont create tmp upload dirs in webroot, this is classic way of 
>> showing no care
> 
> DocumentRoot is /var/www/$domain/$host/public

and so open_basedir should be the same and *not* include
"upload_tmp_dir" and "session.save_path", otherwise this
all is nonsense from security point of view

and to come back to topic:
do *not* install a public webserver on your mailserver - period



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Encryption solution for messages at rest

[Frerich Raabe]

On 2013-10-30 16:03, Miquel van Smoorenburg wrote:

On 28/10/13 23:22, Frerich Raabe wrote:
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.


[..]


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.


The whole idea of using asymmetric encryption was that the server
*does not* have the private key. It only has the public key, so it
can store incoming mail encrypted using the users public key (which
requires no password). Dovecot would then just serve the encrypted
mail, all encryption would happen on the client side using the private
key which only the client has.

In the case of Maildir, I suspect (but I don't know) that Dovecot
doesn't treat the individual files as plain data: it does look into 
them

when serving (not only when indexing) to parse some headers or so. So
I guess you cannot just encrypt the raw file on disk but you rather 
have
to "rewrite" the mail so that only the body is encrypted but the 
headers

are left untouched. This means that a hostile root user could see the
headers, but at least not the body of the message.

--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing

Re: [Dovecot] Encryption solution for messages at rest

[Miquel van Smoorenburg]

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.

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/30/2013 09:01 AM, Benny Pedersen wrote:
> Michael Orlitzky skrev den 2013-10-28 20:49:
> 
>>   php_admin_value open_basedir /var/www/$domain/$host/
>>   php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
>>   php_admin_value session.save_path /var/www/$domain/$host/tmp
>>   php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
> 
> so dont create tmp upload dirs in webroot, this is classic way of 
> showing no care
> 

DocumentRoot is /var/www/$domain/$host/public.

Re: [Dovecot] Encryption solution for messages at rest

[Benny Pedersen]

Michael Orlitzky skrev den 2013-10-28 20:49:


  php_admin_value open_basedir /var/www/$domain/$host/
  php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
  php_admin_value session.save_path /var/www/$domain/$host/tmp
  php_admin_value sys_temp_dir /var/www/$domain/$host/tmp


so dont create tmp upload dirs in webroot, this is classic way of 
showing no care

Re: [Dovecot] Encryption solution for messages at rest

[Ed W]

I think your problem can be more generically restated as:

- Untrusted users have access to the mailstore, eg employees who 
maintain the server, attackers who break into the system as untrusted 
user accounts
- There is some trusted process to get access to decryption keys and 
largely this process is secure (obviously except attacks which succeed 
to escalate to root, or if employees typically get root access)

- How to extend this secure key access process to dovecot

So Exchange offers this feature where you can encrypt the mail and grant 
specific users access to decrypt subsets of the mail. This means that 
employees managing the mail server may not have access to decrypt the 
messages for their boss, etc (without at least using trickery to bypass 
and escalate their privileges - of course this is always possible, 
especially with physical access, but it reduces the attack surface)


Off the top of my head it seems like any attempts to do this using block 
disk encryption layers substantially boil down to equivalent to standard 
file permissions. eg adding ecryptfs on the mail store means you need to 
prevent access to the mounted decrypted files, which given the mail 
store is a long running process, is largely equivalent to just using 
file permissions, MAC, grsec, etc to protect the dir?


Timo's suggestion to incorporate in Dovecot opens up possible solutions. 
ie now files can be decrypted *as* they are required by the mail server. 
decryption key can probably be stored in userdb without loss of privacy 
(since if you can get the password for the account you can just pickup 
the emails via imap?). Bonus marks if you design some encrypted key 
store, but is seems challenging to add value here, possibly against more 
specific attacks, eg you don't want your database DBA to be able to get 
access to the decryption keys, hence a separate (simple) database just 
for decryption keys moves the problem sideways.


Using Timo's filter this all seems very do-able, but performance will 
obviously be impacted. Modern processers are very fast at certain types 
of encryption opts though..?


I'm interested to see what you produce.  Seems interesting, but as many 
have already commented, it really only defends against a limited attack 
surface and not at all if the dovecot process or root/dovecot user is 
compromised.  I think corporates would quite like this feature though


Ed W


On 28/10/2013 19:14, Douglas Mortensen wrote:

Currently our dovecot servers are on our webhosting linux boxes. We are using the 
LAMP stack to host websites, and also doing email with postfix & dovecot on 
these systems. We provide this as a hosting setup for 100+ accounts/websites on a 
single server (a multi-tenant setup). Each customer has anywhere between 1-100 
email accounts which Dovecot services.

If a customer has vulnerable PHP code on a website, some of these will allow a 
remote file upload. I have seen cases where they upload a PHP script that is a 
sort of web-based console/shell to the server (file-system, etc.). It provides 
several tools which all run through the uploaded PHP script to try to brute 
force and do other attacks. I've seen attempts at a root exploit. We've never 
had a root exploit and any such case of a customer's site being hacked has been 
easily contained by simple filesystem permissions being correct (and the fact 
that we have apache setup to run all scripts as the user who is the owner of 
the script files, which confines the script to that users' permissions). Still 
nobody loves the idea of bad guys trying to hack on your box.

So given that type of scenario, if filesystem permissions weren't correct, 
or some new exploit surfaced that allowed someone bypass or elevate to root, 
then they could theoretically have access to the entire fileystem including 
where emails are stored.

I hope to never have this sort of thing happen. We patch our systems regularly 
and have other security measures we follow to prevent this. We also are 
managing most of the PHP scripts customers use ourselves now and are updating 
those for the CMS' and other systems proactively.

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.
-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300

-Original Message-
From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On 
Behalf Of Michael Orlitzky
Sent: Monday, October 28, 2013 11:52 AM
To: dovecot
Subject: Re: [Dovecot] Encryption solution for messages at rest

On 10/28/2013 12:02 PM, Douglas Mortensen wrote:

Hi,

We have clients with various security & compliance requirements.
Although not required, it would be ideal to have messages encrypted at
rest.

You can rule out a l

Re: [Dovecot] Encryption solution for messages at rest

[Douglas Mortensen]

So I suppose you're not a fan of the email hosting systems on the planet that 
bundle many services onto 1 box. Thanks for the feedback.

-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300

-Original Message-
From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On 
Behalf Of Alan Brown
Sent: Tuesday, October 29, 2013 10:05 AM
To: dovecot
Subject: [Dovecot] Encryption solution for messages at rest


> Date: Tue, 29 Oct 2013 08:54:04 +0100
> From: Robert Schetterer 
> To: dovecot@dovecot.org
> Subject: Re: [Dovecot] Encryption solution for messages at rest
> Message-ID: <526f699c.9080...@sys4.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> you shouldnt host mail/imap services on the same servers with massive 
> http hosting,


You shouldn't host anything else on a webserver FULLSTOP.

Webservers are best treated as "disposable" and should be heavily sandboxed. 
Any resources they can use should be vetted and ideally set as "read only"

Inbound external access should be firewalled down to the webserver ports and 
OUTBOUND traffic should be firewalled too (If it has no business initiating 
external connections then block all SYNs), in order to stop it becoming a DDoS 
zombie.

It's foolish (at best) to have mail servers running on a webserver, because if 
it's compromised it can immediately be used as a spam engine without much 
further effort.

At least if it has to hand mail off to another mailserver you have a chance to 
run outbound filtering on the emitted mail without worrying about that being 
compromised too.

Re: [Dovecot] Encryption solution for messages at rest

[Timo Sirainen]

On 28.10.2013, at 18.02, Douglas Mortensen  wrote:

> We have clients with various security & compliance requirements. Although not 
> required, it would be ideal to have messages encrypted at rest. We already 
> use SSL/TLS to secure the transmission of most email. However, it would be 
> nice to have them encrypted sitting on our server. Is anyone doing this? I 
> think that ideally, rather than full-disk encryption, we should use an 
> encryption that encrypts the actual email messages as they sit on our file 
> system. This way even if we ever had our server breached by an attacker, they 
> wouldn't be able to do anything with the messages. However, this would also 
> mean that if the attacker can't decrypt the files, than dovecot and postfix 
> still would need to. This means that the encryption key would need to be 
> available to the dovecot deamon. We'd either need to have it in a file that 
> is restricted to access only by dovecot (less secure), or use an encryption 
> passphrase for the certificate which would have to be typed in manually each 
> time that dovecot starts or restarts (more secure, but also more work and 
> possibility of disruption because the server can't restart gracefully without 
> a human being having to be present [although I don't think we have issues 
> with unexpected restarts anyway]).
> 
> Is anyone doing anything like this with dovecot?

http://dovecot.org/patches/2.2/mail-filter.tar.gz could be used as the base for 
this.

[Dovecot] Encryption solution for messages at rest

[Alan Brown]

Date: Tue, 29 Oct 2013 08:54:04 +0100
From: Robert Schetterer 
To: dovecot@dovecot.org
Subject: Re: [Dovecot] Encryption solution for messages at rest
Message-ID: <526f699c.9080...@sys4.de>
Content-Type: text/plain; charset=ISO-8859-1


you shouldnt host mail/imap services on the same servers with massive
http hosting,



You shouldn't host anything else on a webserver FULLSTOP.

Webservers are best treated as "disposable" and should be heavily 
sandboxed. Any resources they can use should be vetted and ideally set 
as "read only"


Inbound external access should be firewalled down to the webserver ports 
and OUTBOUND traffic should be firewalled too (If it has no business 
initiating external connections then block all SYNs), in order to stop 
it becoming a DDoS zombie.


It's foolish (at best) to have mail servers running on a webserver, 
because if it's compromised it can immediately be used as a spam engine 
without much further effort.


At least if it has to hand mail off to another mailserver you have a 
chance to run outbound filtering on the emitted mail without worrying 
about that being compromised too.

Re: [Dovecot] Encryption solution for messages at rest

[Robert Schetterer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 29.10.2013 02:17, schrieb Noel Butler:
> On 29/10/2013 03:19, Robert Schetterer wrote:
> 
>> 
>> 
>> https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-sieve
>>
>
>> 
> 
> I got worried, laughed, and stopped reading at:
> 
> "not only do you not have to edit any Postfix configuration (which
> by itself is an exercise in patience),"
> 
> 
> As you know, postfix can be done in your sleep, if he thinks he
> needs patience to do postfix, I should introduce him to sendmail
> configuration (which I also think is easy - but having used it for
> 15 years before moving to postix, I guess it would want to be easy
> LOL) :)
> 

Hi Noel, its not my blog, and the main thing i looked at, is how to
connect dove external sieve plugin with gpg,  youre right postfix has
well done docs and mail list, so i simply rare care about postfix
statements written elsewhere.

Best Regards
MfG Robert Schetterer

- -- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSb2usAAoJEP8jBObu0LlEFjcIAMtuDU5+0lBdZ+2OUm9NLOIo
8nG/fk7zGzkdR5ULix7/iLeyegZ0ngt5o5FOKJzSKGfZvzdc5yrFHhTEX7ejzhTn
2vnckCJQfTV8mCO1Y0d5PKxKxCUPKOjcRHRdhcRdbT5sVsyxvPaBeKkiaxm8gDr6
+VaWjyTXPghMyOTppKNj8N9v1q8Dcm94Apt987I4pskbTDxLZJWwGbzOxc5m4Ejn
wUCLW6ykav/zZL04T8/qDuXQ5YdEICiGAylZaPqjgz4J9uevr/xsKNCWEFgQ+2W3
hmQDJhivi+QZd5YnkhUU7Hy84U1eIOmAFgaFrZk4ZtrK89Q51JqYlfLw9jYpZ3E=
=dAXz
-END PGP SIGNATURE-

Re: [Dovecot] Encryption solution for messages at rest

[Robert Schetterer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 28.10.2013 20:14, schrieb Douglas Mortensen:
> Currently our dovecot servers are on our webhosting linux boxes. We
> are using the LAMP stack to host websites, and also doing email
> with postfix & dovecot on these systems. We provide this as a
> hosting setup for 100+ accounts/websites on a single server (a
> multi-tenant setup). Each customer has anywhere between 1-100 email
> accounts which Dovecot services.
> 
> If a customer has vulnerable PHP code on a website, some of these
> will allow a remote file upload. I have seen cases where they
> upload a PHP script that is a sort of web-based console/shell to
> the server (file-system, etc.). It provides several tools which all
> run through the uploaded PHP script to try to brute force and do
> other attacks. I've seen attempts at a root exploit. We've never
> had a root exploit and any such case of a customer's site being
> hacked has been easily contained by simple filesystem permissions
> being correct (and the fact that we have apache setup to run all
> scripts as the user who is the owner of the script files, which
> confines the script to that users' permissions). Still nobody loves
> the idea of bad guys trying to hack on your box.
> 
> So given that type of scenario, if filesystem permissions
> weren't correct, or some new exploit surfaced that allowed someone
> bypass or elevate to root, then they could theoretically have
> access to the entire fileystem including where emails are stored.
> 
> I hope to never have this sort of thing happen. We patch our
> systems regularly and have other security measures we follow to
> prevent this. We also are managing most of the PHP scripts
> customers use ourselves now and are updating those for the CMS' and
> other systems proactively.
> 
> 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. - Doug Mortensen Network Consultant 
> Impala Networks P: 505.327.7300


you shouldnt host mail/imap services on the same servers with massive
http hosting, i dont see a real connection between php bugs etc and
dovecot, it more a question of setup design you have choosen what
makes thing more bad then they have to be

> 
> -Original Message- From: dovecot-boun...@dovecot.org
> [mailto:dovecot-boun...@dovecot.org] On Behalf Of Michael Orlitzky 
> Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re:
> [Dovecot] Encryption solution for messages at rest
> 
> On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
>> Hi,
>> 
>> We have clients with various security & compliance requirements. 
>> Although not required, it would be ideal to have messages
>> encrypted at rest.
> 
> You can rule out a lot of the crazier options by answering the
> questions,
> 
> (a) What attack scenario do you have in mind?
> 
> (b) How will encryption help?
> 


Best Regards
MfG Robert Schetterer

- -- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSb2mWAAoJEP8jBObu0LlEWkAH+gImez3F9cz1c5TcbgWTMdP6
onrp2Swd5gw6bKNkj2R6bzvtNPTNtrCUxVNU8c8YIIyeMK+fq3d6YxjB8p5nwrrR
AqL82xo97CbjPluldrcUAZUzBSUMrIjXC4dKAQvpD/Nhl7QMmPmeCcvZ8B39urcs
4AT2vSDI5wvuMtpKzj2ohA5P9UAwDPmm6beihWn73IubCWeUcO47sJj4W0dnO2bv
OZ2k6TwLfRbdkqH3wH0JEGqnYgrRxm9czkidH1C5JJM5MAosJoTn21dSbLZoqD8O
pmdT7jqUfyZ1GkUDO2OqEHl1V04RQhlP0wxAKTh39ahvQrXZgPzTwhxw6T0cZoM=
=zZYc
-END PGP SIGNATURE-

Re: [Dovecot] Encryption solution for messages at rest

[Noel Butler]

On 29/10/2013 03:19, Robert Schetterer wrote:




https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-sieve




I got worried, laughed, and stopped reading at:

"not only do you not have to edit any Postfix configuration (which by 
itself is an exercise in patience),"



As you know, postfix can be done in your sleep, if he thinks he needs 
patience to do postfix, I should introduce him to sendmail configuration 
(which I also think is easy - but having used it for 15 years before 
moving to postix, I guess it would want to be easy LOL) :)

Re: [Dovecot] Encryption solution for messages at rest

[Frerich Raabe]

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.


--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing

Re: [Dovecot] Encryption solution for messages at rest

[Reindl Harald]

Am 28.10.2013 20:49, schrieb Michael Orlitzky:
> On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
>> If a customer has vulnerable PHP code on a website, some of these
>> will allow a remote file upload. I have seen cases where they upload
>> a PHP script that is a sort of web-based console/shell to the server
>> (file-system, etc.). It provides several tools which all run through
>> the uploaded PHP script to try to brute force and do other attacks.
>> I've seen attempts at a root exploit. We've never had a root exploit
>> and any such case of a customer's site being hacked has been easily
>> contained by simple filesystem permissions being correct (and the
>> fact that we have apache setup to run all scripts as the user who is
>> the owner of the script files, which confines the script to that
>> users' permissions). Still nobody loves the idea of bad guys trying
>> to hack on your box.
> 
> If an attacker gets root, the entire exercise is pointless, because he
> can get the decryption key. So you "don't have to worry" about that case =)
> 
> A suggestion, not dovecot-related:
> 
> The web users -- in our case, www.example.com -- shouldn't have access
> to anything outside of the web root. You can achieve this within PHP by
> placing everything that the website will need under one directory, and
> setting (in apache):
> 
>   php_admin_value open_basedir /var/www/$domain/$host/
>   php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
>   php_admin_value session.save_path /var/www/$domain/$host/tmp
>   php_admin_value sys_temp_dir /var/www/$domain/$host/tmp

oh no - do *not* place the sesiondata anywhere inside open_basdir
this is one of the badest things you can do because any otherwise
harmless script bypassed whatever security restriction will
be able to read *any* session data

but hey, also PHP upstream a few years ago had no clue about session-security

https://bugs.php.net/bug.php?id=42077



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
> If a customer has vulnerable PHP code on a website, some of these
> will allow a remote file upload. I have seen cases where they upload
> a PHP script that is a sort of web-based console/shell to the server
> (file-system, etc.). It provides several tools which all run through
> the uploaded PHP script to try to brute force and do other attacks.
> I've seen attempts at a root exploit. We've never had a root exploit
> and any such case of a customer's site being hacked has been easily
> contained by simple filesystem permissions being correct (and the
> fact that we have apache setup to run all scripts as the user who is
> the owner of the script files, which confines the script to that
> users' permissions). Still nobody loves the idea of bad guys trying
> to hack on your box.

If an attacker gets root, the entire exercise is pointless, because he
can get the decryption key. So you "don't have to worry" about that case =)

A suggestion, not dovecot-related:

The web users -- in our case, www.example.com -- shouldn't have access
to anything outside of the web root. You can achieve this within PHP by
placing everything that the website will need under one directory, and
setting (in apache):

  php_admin_value open_basedir /var/www/$domain/$host/
  php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
  php_admin_value session.save_path /var/www/$domain/$host/tmp
  php_admin_value sys_temp_dir /var/www/$domain/$host/tmp

Personally, I don't trust PHP at all, so we create a separate web user
for each vhost and run them under mpm-itk .


> So given that type of scenario, if filesystem permissions weren't
> correct, or some new exploit surfaced that allowed someone bypass or
> elevate to root, then they could theoretically have access to the
> entire fileystem including where emails are stored.

Who has access to the maildirs on your systems? On ours, everything is
owned by deliver:deliver, with mode 700 or 600. The dovecot 'deliver'
user is the one who reads and writes all mail. (It is in fact a misnomer
now that we use LMTP). You can achieve the same by setting mode=600
everywhere in dovecot.conf, but this depends on your setup.

Suppose someone gains access to the 'deliver' user. That user is the one
who reads and would decrypt the mail; therefore the attacker can read
the mail anyway. But if they don't gain access to the 'deliver' account,
what can they do? Barring incorrect permissions or a kernel bug, nothing.

The permissions are handled by dovecot, which ostensibly you trust. And
if there's a kernel bug, you have bigger problems.

Re: [Dovecot] Encryption solution for messages at rest

[Ron Leach]

On 28/10/2013 19:14, Douglas Mortensen wrote:


So given that type of scenario, if filesystem permissions
weren't correct, or some new exploit surfaced that allowed someone
bypass or elevate to root, then they could theoretically have
access to the entire fileystem including where emails are stored.

...

>

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.


OK, but encryption will only help if the bad guy, who gets elevated to 
root, can not access the decryption keys.  But you initially suggested 
Dovecot has to decrypt the mails, so I would think root access would 
be able to obtain keys and run (in some manner) suitable decryption, 
even if offline back in its lair.


And this brings me to something I wanted to ask from your first post - 
and please forgive a basic question.  Why does Dovecot need to decrypt 
the messages?  Why could not the messages be encrypted, and only the 
clients decrypt them - this way only the clients would have the 
decryption keys and the bad root-guy can't get the keys.


Is true that Dovecot needs access to mails in clear?  If yes, what 
part of the mails does Dovecot need in clear - might clear 'headers' 
be sufficient for its purposes, so that message content remains encrypted?


Such a scenario might require all users (or, maybe, just those users 
that wanted this facility) to ensure they had suitable clients, maybe 
Thunderbird with a suitable plug-in, or maybe a special-purpose 
client.  And whatever public email server you (or the customers) are 
running would have to encrypt public email on receipt, and decrypt on 
public transmission, but 'in-company' email within each customer could 
remain encrypted, anyway.


Such a scheme would depend, though, on the extent to which Dovecot 
does require access to mail 'content' (in addition to Dovecot 
housekeeping data such as time of receipt, read status, index value, etc).


Hence the question, does Dovecot need access to mail in clear?

regards, Ron

Re: [Dovecot] Encryption solution for messages at rest

[Reindl Harald]

Am 28.10.2013 20:14, schrieb Douglas Mortensen:
> So given that type of scenario, if filesystem permissions weren't 
> correct, or some new exploit surfaced that allowed someone bypass or elevate 
> to root, then they could theoretically have access to the entire fileystem 
> including where emails are stored.
> I hope to never have this sort of thing happen. We patch our systems 
> regularly and have other security measures we follow to prevent this. We also 
> are managing most of the PHP scripts customers use ourselves now and are 
> updating those for the CMS' and other systems proactively.

how would enryption help here?

> 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

encryption is nice in case of disks got stolen but not for
protection against intrusion on the running machine

> -Original Message-
> From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On 
> Behalf Of Michael Orlitzky
> Sent: Monday, October 28, 2013 11:52 AM
> To: dovecot
> Subject: Re: [Dovecot] Encryption solution for messages at rest
> 
> On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
>> Hi,
>>
>> We have clients with various security & compliance requirements.
>> Although not required, it would be ideal to have messages encrypted at 
>> rest.
> 
> You can rule out a lot of the crazier options by answering the questions,
> 
> (a) What attack scenario do you have in mind?
> 
> (b) How will encryption help?



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Encryption solution for messages at rest

[Douglas Mortensen]

Currently our dovecot servers are on our webhosting linux boxes. We are using 
the LAMP stack to host websites, and also doing email with postfix & dovecot on 
these systems. We provide this as a hosting setup for 100+ accounts/websites on 
a single server (a multi-tenant setup). Each customer has anywhere between 
1-100 email accounts which Dovecot services.

If a customer has vulnerable PHP code on a website, some of these will allow a 
remote file upload. I have seen cases where they upload a PHP script that is a 
sort of web-based console/shell to the server (file-system, etc.). It provides 
several tools which all run through the uploaded PHP script to try to brute 
force and do other attacks. I've seen attempts at a root exploit. We've never 
had a root exploit and any such case of a customer's site being hacked has been 
easily contained by simple filesystem permissions being correct (and the fact 
that we have apache setup to run all scripts as the user who is the owner of 
the script files, which confines the script to that users' permissions). Still 
nobody loves the idea of bad guys trying to hack on your box.

So given that type of scenario, if filesystem permissions weren't correct, 
or some new exploit surfaced that allowed someone bypass or elevate to root, 
then they could theoretically have access to the entire fileystem including 
where emails are stored.

I hope to never have this sort of thing happen. We patch our systems regularly 
and have other security measures we follow to prevent this. We also are 
managing most of the PHP scripts customers use ourselves now and are updating 
those for the CMS' and other systems proactively.

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.
-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300

-Original Message-
From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On 
Behalf Of Michael Orlitzky
Sent: Monday, October 28, 2013 11:52 AM
To: dovecot
Subject: Re: [Dovecot] Encryption solution for messages at rest

On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
> Hi,
> 
> We have clients with various security & compliance requirements.
> Although not required, it would be ideal to have messages encrypted at 
> rest.

You can rule out a lot of the crazier options by answering the questions,

(a) What attack scenario do you have in mind?

(b) How will encryption help?

Re: [Dovecot] Encryption solution for messages at rest

[Michael Orlitzky]

On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
> Hi,
> 
> We have clients with various security & compliance requirements.
> Although not required, it would be ideal to have messages encrypted
> at rest.

You can rule out a lot of the crazier options by answering the questions,

(a) What attack scenario do you have in mind?

(b) How will encryption help?

Re: [Dovecot] Encryption solution for messages at rest

[Robert Schetterer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 28.10.2013 17:02, schrieb Douglas Mortensen:
> Hi,
> 
> We have clients with various security & compliance requirements.
> Although not required, it would be ideal to have messages encrypted
> at rest. We already use SSL/TLS to secure the transmission of most
> email. However, it would be nice to have them encrypted sitting on
> our server. Is anyone doing this? I think that ideally, rather than
> full-disk encryption, we should use an encryption that encrypts the
> actual email messages as they sit on our file system. This way even
> if we ever had our server breached by an attacker, they wouldn't be
> able to do anything with the messages. However, this would also
> mean that if the attacker can't decrypt the files, than dovecot and
> postfix still would need to. This means that the encryption key
> would need to be available to the dovecot deamon. We'd either need
> to have it in a file that is restricted to access only by dovecot
> (less secure), or use an encryption passphrase for the certificate
> which would have to be typed in manually each time that dovecot
> starts or restarts (more secure, but also more work and possibility
> of disruption because the server can't restart gracefully without a
> human being having to be present [although I don't think we have
> issues with unexpected restarts anyway]).
> 
> Is anyone doing anything like this with dovecot?

perhaps
look at

https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-sieve

> 
> Thanks!! - Doug Mortensen Network Consultant Impala Networks Inc 
> CCNA, MCSA, Security+, A+ Linux+, Network+, Server+ A.A.S.
> Information Technology . www.impalanetworks.com P: (505) 327-7300 
> F: (505) 327-7545
> 


Best Regards
MfG Robert Schetterer

- -- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSbpyxAAoJEP8jBObu0LlEFmUH/0i8vKvqvIC9d3AX/QHpd7G6
+ybdiRsndYnyrOMVoRf/P0L9S2QL/FY/stQ3s4xmIZbZAlh2qQI6PhcZRPDJD1pA
59bJppKwZmm37+uj+gEYgNWdG08Adtr9xsreKvYr97Un/9W/psXYxstswITLXC9Q
8/7n4S/GBUkG36924EvtSr+nrl5HrMKgY9H5XBVz/KAauK6NYy9A3UyiaNaGVgnJ
Sd58ZgMKuk84pkSFov+uj5VNz84btyfH3JQowZwN3tN8hxrmqDdkEpO38LB87PMX
/sJprTisgS5WetB9GOXcSY2rbpE7I5uL3VycA/46nB1PQHe2zRY9ZQEdTNHOiTQ=
=NEp8
-END PGP SIGNATURE-

[Dovecot] Encryption solution for messages at rest

[Douglas Mortensen]

Hi,

We have clients with various security & compliance requirements. Although not 
required, it would be ideal to have messages encrypted at rest. We already use 
SSL/TLS to secure the transmission of most email. However, it would be nice to 
have them encrypted sitting on our server. Is anyone doing this? I think that 
ideally, rather than full-disk encryption, we should use an encryption that 
encrypts the actual email messages as they sit on our file system. This way 
even if we ever had our server breached by an attacker, they wouldn't be able 
to do anything with the messages. However, this would also mean that if the 
attacker can't decrypt the files, than dovecot and postfix still would need to. 
This means that the encryption key would need to be available to the dovecot 
deamon. We'd either need to have it in a file that is restricted to access only 
by dovecot (less secure), or use an encryption passphrase for the certificate 
which would have to be typed in manually each time that dovecot starts or 
restarts (more secure, but also more work and possibility of disruption because 
the server can't restart gracefully without a human being having to be present 
[although I don't think we have issues with unexpected restarts anyway]).

Is anyone doing anything like this with dovecot?

Thanks!!
-
Doug Mortensen
Network Consultant
Impala Networks Inc
CCNA, MCSA, Security+, A+
Linux+, Network+, Server+
A.A.S. Information Technology
.
www.impalanetworks.com
P: (505) 327-7300
F: (505) 327-7545