On Fri, Sep 20, 2013 at 09:27:57AM -0500, Noel Jones wrote:
> Without close cooperation from the remote site, fingerprint
> verification just isn't practical. For an arbitrary third-party
> site, you'll probably need to stick to "encrypt" or maybe in some
> cases "verify".
> http://www.postfix.org/TLS_README.html#client_tls
One should generally use "secure", not "verify". It was mistake
on my part to create both security levels, they differ only in the
default matching strategy. We should have had a single level with
a configurable global matching strategy (smtp_tls_verify_cert_match)
that defaults safe, and with the per-site "match" overrides allowing
users to fine-tune as necessary.
Instead we have "verify" and "secure' that differ only in the unsafe
setting of smtp_tls_verify_cert_match vs. a safe setting for the
analogous smtp_tls_secure_cert_match.
Users should probably set:
# Default MITM safe matching (as in "secure")
smtp_tls_verify_cert_match = nexthop, dot-nexthop
smtp_tls_secure_cert_match = nexthop, dot-nexthop
# Default MITM unsafe matching (as in "verify")
smtp_tls_verify_cert_match = hostname
smtp_tls_secure_cert_match = hostname
and then use the two levels interchangeably.
[ Don't try to alias one in terms of the implicit default value of
the other, Postfix configuration parameter expansion happens
incrementally, and the defaults are not all set when parameters
are expanded. ]
> Hopefully widespread DANE adoption will take the pain out of this
> in the future.
Amen.
--
Viktor.
