On Mon, Mar 17, 2014 at 03:17:01PM +0100, Ralf Hauser wrote:

> > 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?
> 
> 1) reliable audit trail: 
> with  "smtp_tls_loglevel = 1", I see for example 
>
> << Trusted: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) >>
>
> So, I know that good symmetric ciphers and forward secret handshake have
> been used, but I have a hard time to reconstruct whether the private key
> used for decryption belongs to a person I want to be able to read the
> contents or not.

If you're looking for key continuity, my intention is to wait for
the TLS Tack extension to be adopted by OpenSSL and to figure out
how to combine it with DANE to solve both the introduction and key
continuity problems.

> Adding the fingerprint as in
> http://www.postfix.org/TLS_README.html#client_tls_fprint (SHA1 or SHA256 as
> default digest) would be very helpful here as well as in
> "smtp_tls_note_starttls_offer".

We could consider (optionally?) logging the peer public key
fingerprint at level 1.  However, you're rather missing the point
about "smtp_tls_note_starttls_offer".  Logging the digest there is
obviously impossible, and since it is likely you have opportunistic
TLS enabled by default, this is entirely irrelevant for your case.

> 2) suggestions for upgrade to mandatory TLS: while opportunistic TLS
> messages are sent over time, I would like to analyze whether there is many
> changes in certificates seen per receiving domain/server (MITM activity?!?)

You won't learn much.  Sites with public CA issued certs will
replace them when (or often just after) they are about to expire.
Sites with self-issued certs almost never change them.  The odds
that someone is performing MITM SSL attacks on your Postfix server
are slim.

> In the latter case, I want to suggest to the senders to change from
> opportunistic TLS to mandatory TLS

Your system is the sender.  You should not unilaterally enable
mandatory TLS to remote sites without coordination with their
postmaster.  If you want Postfix to suggest *mandatory* TLS,
this does not require any information about certificates, just
audit the logs for sites to which all deliveries are via TLS.
Mandatory TLS ("encrypt" security level) need not require any
certificates.

To secure your outbound email just enable opportunistic TLS or
opportunistic DANE TLS.  Anything beyond that is likely unwarranted
at this time.

-- 
        Viktor.

Reply via email to