http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTtlssni
If the string |tls_in_sni| appears in the main section’s
tls_certificate option (prior to expansion) then the following
options will be re-expanded during TLS session handshake, to permit
alternative values to be chosen:
o
tls_certificate
o
tls_crl
o
tls_privatekey
o
tls_verify_certificates
o
tls_ocsp_file
Unless it is indeed possible somehow, for the exim process to """regain
privs by exec'ing a new Exim""", I do indeed not have much hope to have
ever see my idea (aquire a file descriptor to the private key file early
on, as root) implemented, at least not as long as "|tls_in_sni| appears
in the main section’s tls_certificate option". Anyhow, it could be
arranged for the feature to only be effective for the opposite case
(i.e. |tls_in_sni| NOT appearing in the main section’s tls_certificate
option, couldn't it?
On 2017-08-18 20:43, Patrick Pfeifer wrote:
> |Aha. As it happens, I found the answer to my last question already.
> E.g. here: https://github.com/serghey-rodin/vesta/issues/1211
> tls_privatekey = ${if
> exists{/usr/local/vesta/data/ssl_pool/${tls_sni}.key}{/usr/local/vesta/data/ssl_pool/${tls_sni}.key}{/usr/local/vesta/ssl/certificate.crt}}
> Now the hurdle appears already substantially higher. :-) ... |
> vv s/,soes not have/,the exim4 binary does not have/ vv
>
> On 2017-08-18 20:33, Patrick Pfeifer via Exim-users wrote:
>> On 2017-08-18 20:12, Jeremy Harris wrote:
>>> First, you don't need to copy exim-dev as well as exim-users.
>>> Devs will be reading both.
>> Ok. Sorry about the noise.
>>> Exim does as little work as possible while in a privileged state, and
>>> drops privs to do the rest. To regain privs it execs a new Exim.
>> Aha. Not in my setup though. (I see only one Exim process with UID
>> Debian-exim and I see no way that it could re-gain privs, although
>> root-owned, soes not have the suid bit set.)
>>> The cert and privatekey files used can depend on information only
>>> available immediately before they are needed (such as the remote IP).
>>> As such they are only read at that time.
>> Aha. Well, that feature is putting some hurdle to the implementation
>> of my idea somehow. How is it activated?
>>
>> Actually /all/ those certificates could / would then just need to be
>> read into memory (or a file descriptor to them acquired) early on,
>> i.e. as root. I imagine that it the number of keys is reasonably
>> small for a typical setup - but I have no clue about such setups
>> actually (?).
>>
>> Or would that already be too much of a security threat in your eyes
>> as well? ... Actually I would argue against it, as with the current
>> setup Exim has access to all key files anyway. ...
>>
>
