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.