Mail-crypt plugin clarification

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
rje
Reply | Threaded
Open this post in threaded view
|

Mail-crypt plugin clarification

rje
I'm looking into ways to encrypt the stored email on my server. The idea is
to make it impossible for my hosting provider (who has access to my VPS) to
read the mail from the disk.

So I'm looking into ways to do this, and I found the mail-crypt plugin for
dovecot. Unfortunately I find the documentation very hard to understand.
There is no clear description of what the goal and purpose of the plugin is,
or how it works. Most of the documentation is very short and provides no
explanation. So here are some questions - I will gladly help to update the
documentation when some of these questions are answered :) If you cannot
answer them all, please tell me what you know..

- It seems mail-cypt will transparently encrypt/decrypt mail - so it stores
it on the server in encrypted form, but dovecot serves it unencrypted over
IMAP. Is this correct?

- It seems that mail-crypt needs both a private and a public key to work. Is
this correct?

- If mail-crypt has both private and public key in its configuration, does
that not defeat the purpose of the whole thing? Anyone with access to the
disk will be able to read everything?

Regarding the settings:

mail_crypt_global_private_key(_n) - Private key to decrypt files, you can
specify many
mail_crypt_global_public_key - Public key to use to encrypt files, you can
specify one

- How does this work? What does mail-crypt do when multiple private keys are
specified?

mail_crypt_private_key - Private key to decrypt user's master key, can be
base64 encoded
mail_crypt_private_password - Password to decrypt user's master key or
environment private key

- What is the relation between a users master key, and the private/public
global keys above? What is an environment private key?

TIA, and as I said above, I will help with updating the docs!



--
Sent from: http://dovecot.2317879.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Mail-crypt plugin clarification

Joseph Tam-2
rje writes:

> I'm looking into ways to encrypt the stored email on my server. The idea is
> to make it impossible for my hosting provider (who has access to my VPS) to
> read the mail from the disk.

Just to be clear, if at any point your VPS has access to the plaintext
mail (or keys that decrypt mail), then the VPS provider could access
your decrypted mail.

To make it unfeasible for your VPS to read your mail, it has to arrive
at your VPS pre-encrypted.  I can envision a system where you import
encrypted mail into your mail store, then use client IMAP access to
be decrypted locally by your mail reader.  However, metadata is still
accessible by your VPS provider.

If your VPS is the MTA that directly handles SMTP from your correspondees
sending you unencrypted messages, you can't lock out a sufficiently
skilled platform admin.

Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Mail-crypt plugin clarification

Aki Tuomi-2


On 14.12.2017 01:07, Joseph Tam wrote:

> rje writes:
>
>> I'm looking into ways to encrypt the stored email on my server. The
>> idea is
>> to make it impossible for my hosting provider (who has access to my
>> VPS) to
>> read the mail from the disk.
>
> Just to be clear, if at any point your VPS has access to the plaintext
> mail (or keys that decrypt mail), then the VPS provider could access
> your decrypted mail.
>
> To make it unfeasible for your VPS to read your mail, it has to arrive
> at your VPS pre-encrypted.  I can envision a system where you import
> encrypted mail into your mail store, then use client IMAP access to
> be decrypted locally by your mail reader.  However, metadata is still
> accessible by your VPS provider.
>
> If your VPS is the MTA that directly handles SMTP from your correspondees
> sending you unencrypted messages, you can't lock out a sufficiently
> skilled platform admin.
>
> Joseph Tam <[hidden email]>

Hi!

Dovecot does support making it difficult to prevent access to the stored
mail. You can, with suitable workflows, ensure that the user's emails
are not readable by anyone but the user. This can be done by encrypting
the user's private key using user's password (or it's derivate, such as
sha256 sum of it).

Of course the only way to be fully sure is to use end-to-end encryption,
like PGP or S/MIME, but this does go a long way to prevent admin access
to user's email.

Downside of course is that if the user ever forgets his password, then
those emails are lost as well. We have plans to add DR support for this,
but it's still WIP.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: Mail-crypt plugin clarification

Joseph Tam-2
In reply to this post by rje
Aki Tuomi writes:

> Dovecot does support making it difficult to prevent access to the stored
> mail.

Those who have had problems understanding the documentation might find
this unintended double-negative ironically funny.

> You can, with suitable workflows, ensure that the user's emails are not
> readable by anyone but the user.  Of course the only way to be fully
> sure is to use end-to-end encryption, ...

"Ensure" (or OP: "impossible") are very high standards of privacy.
If the OP really means it, then since a third party has control over
the (virtual or real) hardware, the server should never have access to
private keys or decrypted data.  (We're in agreement I think.)

If the OP lowers their standards to "inconvenient" to gain access,
then the plugin is enough.  It will keep the honest admin honest.

> ... like PGP or S/MIME, but this does go a long way to prevent admin access
> to user's email.

Don't ignore metadata; who/when/where (and headers?) could reveal much
information.

Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Mail-crypt plugin clarification

Aki Tuomi-2

> On December 15, 2017 at 2:29 AM Joseph Tam <[hidden email]> wrote:
>
>
> Aki Tuomi writes:
>
> > Dovecot does support making it difficult to prevent access to the stored
> > mail.
>
> Those who have had problems understanding the documentation might find
> this unintended double-negative ironically funny.
>

Indeed. Although we are open to improvements for the documentation, or even pointing out where it's wrong.

> > You can, with suitable workflows, ensure that the user's emails are not
> > readable by anyone but the user.  Of course the only way to be fully
> > sure is to use end-to-end encryption, ...
>
> "Ensure" (or OP: "impossible") are very high standards of privacy.
> If the OP really means it, then since a third party has control over
> the (virtual or real) hardware, the server should never have access to
> private keys or decrypted data.  (We're in agreement I think.)
>

You are quite right. The mail-crypt plugin cannot provide absolute guarantees that the data won't be accessible by sufficiently determined adversary, due to the fact that the keys are indeed on the server, or accessible by the server.

> If the OP lowers their standards to "inconvenient" to gain access,
> then the plugin is enough.  It will keep the honest admin honest.
>
> > ... like PGP or S/MIME, but this does go a long way to prevent admin access
> > to user's email.
>
> Don't ignore metadata; who/when/where (and headers?) could reveal much
> information.
>
> Joseph Tam <[hidden email]>

It's always all about who you are guarding against. I'd say that against your hosting provide, mail crypt can provide reasonable safeguards, especially if the storage is not on the same device.

The weak point is, as you point out, key management and handling, and special attention should be paid to this and I suggest clearly outlining the threats you are planning on mitigating and how the solution(s) you use achieve this.

Aki