On Sun, Feb 23, 2014 at 11:57:35PM +0100, Dirk St?cker wrote:
> >When both sides are Postfix, and the client is opportunistic, the
> >server and client typically agree to a cipher-suite without any
> >certificates. Why bother, if the client does not check anyway.
>
> Because it allows to at to least detect if connection has been
> broken. It is a big difference for later investigation even if not
> for the mail sending at that time.
This is sadly useless. You either have too few CAs to make it
reliable or too many to make it trustworthy. Secure name checks
are not generally possible in the face of arbitrary MX records,
and without name checks validity of the certificate chain is
meaningless.
> Seems Postfix still need to learn a lot about secure connections.
[ Find a newbie to lecture on some other forum. ]
> >If this is important to you, set:
> >
> > smtp_tls_exclude_ciphers=aNULL
> >
> >for the transport that delivers mail between your internal systems.
>
> Does not sound like what I want. I don't want to hard-code a specific
> handling for some servers, I want that the "trusted" state is logged
> properly in any possible case.
In that case, make the setting global. That'll will provide the
desired false sense of security.
> smtp_tls_verify_certs=whenpossible
SMTP is not HTTP. Due to MX indirection, peer authentication is
not possible without explicit per-destination configuration. Once
you've gone to all that trouble, you may as well configure a "secure"
channel.
If you want scalable security for SMTP, become an early adopter of
DANE TLS, available in Postfix 2.11. Today, you'll be able to
opportunistically authenticate the handful of DNSSEC signed domains
that publish TLSA records for SMTP. Over time, I hope that handful
will grow to a decent fraction of SMTP sites.
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane
http://www.postfix.org/TLS_README.html#client_tls_dane
> smtp_tls_remember_certs=yes
This is too brittle. If the TLS TACK draft becomes is adopted as
a standards track RFC, we could look into implementing that. It
requires a robust cache that persists across Postfix restarts, we
probably also need to let the Postfix LMDB support prove its
stability before venturing in that direction.
> and a notice when Cert changed. I.e. with a note like
> (Un)trusted (first seen at 12.01.2014, last change 23.02.2014).
Busy MTAs send mail to a lot of hosts and domains, and their
certificates change from time to time. Naive client-initiated
pinning is too unreliable.
> Also a replacement for "may" which allows to enforce TLS for any
> connection, where TLS worked at least once would improve security.
> That way a system would get more secure the longer it is running.
Ditto.
--
Viktor.
