Author: Phil Pennock Date: To: Adam Spragg CC: exim-users Subject: Re: [exim] Exim SSL/TLS certificate key file permissions/password?
On 2013-09-10 at 01:18 +0100, Adam Spragg wrote: > Looking through the documentation, it seems that the private key file for the
> certificate needs to have read access by the relevant exim group, and also
> must not be password protected.
Others have noted that you need to be careful about what you're trying
to achieve with the password protection. I'll add there that if you
want HSM module support, my assumption is that you're using an OpenSSL
Engine and that environment variables will be sufficient for
configuration. If this is not true, please let us know what is needed
for HSM.
If you're not using an HSM, then the only requirement is that the key
can be read by the Exim run-time user. I happen to recommend that this
be done by leaving the key owned by root, so that *if* there is a
compromise of the run-time user, that can't be used to change the key or
other certificate information used. The keys are assumed to be trusted
and I've no idea what OpenSSL does if you try loading a 65536-bit RSA
key in. That might be a compromise escalation path.
Generally speaking, if you have a user account used for a running daemon
service, as little as possible should be _owned_ by that user account.
The more that is owned, the larger the attack surface in the event of
compromise. Keeping configuration owned by root and readable by the
group is generally better.
What are you putting into the exim run-time group that isn't exim? If
you're putting end-users in, I suggest using the `admin_groups` option
instead and remove those users from the exim group. For myself, I set:
admin_groups = wheel
> Is this really the case? Is there no way to have a well-secured private key
> file, password-protected and only readable by user root? Apache and Dovecot
> manage this by reading the file on startup, before dropping privileges and
> changing to their "normal" uid, and asking for the password on the console. Is
> Exim not able to work this way as well?
Not at present; in addition to source-based dispatch, modern Exim can
also reference $tls_sni in the key and certificate paths, so with an
appropriate lookup in the configuration, the real key and cert filenames
can be coming from a database lookup *during* the TLS handshake.
> I'm not happy having an unprotected private key lying about anywhere, even if
> its permissions were 0400 - let alone 0440 as Exim requires.
>
> If Exim isn't able to do this, does anyone know if there are any plans for it
> in the future?
I can't speak for any of the other devs, but I've no plans to add
read-at-startup. I'd be more interested in adding HSM support, which
*if* you trust the HSM would result in an actual verifiable increase in
security, with private data moving into an entirely different hardware
realm.
If anyone wants HSM support, we'll happily take patches. I'm not
currently paid to work on Exim and don't have the time to do this
myself.
