On Sun, Mar 16, 2014 at 05:04:11PM +0100, Ralf Hauser wrote:
> Fortunately, more and more smtp servers offer STARTTLS.
> I would like to analyze the certificates used when employing STARTTLS
> "opportunistically".
What does "analyze" mean? Certificate chains are often multi-kilobyte
objects (at least the TLS protocol limits them to ~16KB total).
Logging the complete chain with each connection is impractical.
> 4) certificate(-chain) used (e.g. in PEM format)
This is not practical. We could optionally log the public key
digest of the leaf certificate at a lower log level, or if you
really must log the public key digest of each certificate in the
chain. What do you actually want to do with these certificates?
> For efficiency reasons, it would be ok, that after the first insert of a
> certificate only a unique identifier (that would be provided by postfix as
> field 5) would be given (besides a unique id given by postfix, it could also
> be a sha256 digest of the leaf certificate).
>
> Any hints would be appreciated!
You would need to hack this into your own copy of the Postfix TLS
library. src/tls/tls_client.c. Note some sessions are resumed,
and have only a cached leaf certificate, not a complete chain.
You'd want to skip resumed sessions, they always just re-use previous
data.
The TLS library does not currently know the queue-id of the message
being delivered, it only has the server "name[addr]:port" string.
If you must associate the chain data with a message (rather than
a server), you'd need to change the TLS_CLIENT_START() interface.
The logging in question most likely would belong in tlsmgr(8),
which could maintain a small cache of recently seen chains, and
write updates as necessary. So you'd need to extend the tlsmgr(8)
API to receive the complete chain and server name along with any
session lookup key and session to cache.
But what exactly do you actually want to do with all this? I
don't see much point. My recommendation is to wait for
https://tools.ietf.org/html/draft-perrin-tls-tack-02
to mature, then we might figure out a way to employ it for TLS key
continuity in Postfix with DANE for initial introduction. The main
obstacle would be false positives when domains are transferred or
servers are rebuilt without saving keys. It is difficult to
distinguish normal breaks in key continuity from an MITM attack.
We'd need to figure out what to do so as to not require human
intervention. The most likely is to fall back to DANE, but
log any discontinuities in Tack, making MITM visible may be
a sufficient deterrent.
--
Viktor.
