On Mon, Dec 23, 2013 at 09:45:45PM +0100, Andreas Schulze wrote:
> I read up to the bottom. I find the Untrusted/Trusted/Verified explanation
> very useful.
Good.
> But I'm still unsure about what an SMTP client could do
> to change a remote servers state from Trusted to Verified.
If you must-have MITM protection for a particular destination,
configure in smtp_tls_policy_maps a suitable TLS security level
that unconditionally verifies the server, such as:
- fingerprint
- secure
- dane-only (**)
Or to authenticate all servers opportunistically via DANE TLSA records,
set:
smtp_tls_security_level = dane (*)
> (or what's wrong on a server that is only Trusted but not Verified)
If mail delivery proceeded anyway, nothing is wrong: Postfix was
not configured to verify the server certificate. This is the norm,
MX record indirection makes it impossible to verify SMTP servers
without explicit policy entries or help from DNSSEC (hence all
the work to implement DANE support in Postfix 2.11).
If mail delivery did not proceed, then the server certificate did
not contain any of the expected names.
--
Viktor.
(*) Requires Postfix 2.11 on a platform with OpenSSL 1.0.0 or greater,
with EC support not disabled by the vendor. Also requires minimal
DNSSEC support in libresolv (the "DO" and "AD" bits must be
implemented and the option RES_USE_DNSSEC must be defined).
For actual security the MTA needs a DNSSEC validating caching
nameserver on localhost.
Systems with DNSSEC validated MX records and DNSSEC validated
TLSA records for the MX hosts will be subject to mandatory
TLS authentication. Other systems will be subject to
opportunistic TLS.
(**) As above, but secure TLSA RRs are required.
