> On Aug 20, 2017, at 10:54 AM, Jeremy Harris <jgh@???> wrote:
>
> It can still depend on other external factors, due to an expansion
> that doesn't happen to need SNI info. Such as the peer IP, as I
> previously said.
A good and sufficient architectural reason for delayed post
privilege-drop access to the server private keys.
> And even if it didn't use any expansion, we do not want to expand
> the attack surface by doing more work with root privs. As I
> previously said.
Supposing that there were a fixed location to look, the private
keys (and associated certificate chain) of the server are presumably
created by the system administrator (as root), so no new attack
surface would be involved. The system administrator already has
root access. So if the keys were in a fixed location, reading
them as root would not create any new security concerns.
FWIW, though at this time Postfix lacks SNI support, there is some
legitimate demand for SNI, especially for the MSA use-case. Given
the same issue (once the server is talking on the network it is no
longer root), my tentative design for delayed certificate selection
(SNI) in Postfix is to create an indexed file-based (cdb, hash, ...)
key-value store for the associated keys and certificate chain (DER
encoded PKCS#8 and PKCS#7 respectively), and provide a "compiler"
that takes a list of (lookup key, key file, chain file) triples
and builds the key store database. The database would be opened as
root, before dropping privs, and could be accessed directly by the
SMTP server, but might also be accessed indirectly via the "tlsmgr"
service in Postfix. The direct access model could work for Exim,
while of course the "tlsmgr" approach is not architecturally suited.
--
Viktor.
