Postfix: pin key material to our MX:es for fripost.org and its subdomains.

This solves an issue where an attacker would strip the STARTTLS keyword
from the EHLO response, thereby preventing connection upgrade; or spoof
DNS responses to route outgoing messages to an attacker-controlled
SMTPd, thereby allowing message MiTM'ing.  With key material pinning in
place, smtp(8postfix) immediately aborts the connection (before the MAIL
command) and places the message into the deferred queue instead:

    postfix-out/smtp[NNN]: … dsn=4.7.5, status=undeliverable (Server certificate not verified)

This applies to the smarthost as well as for verification probes on the
Mail Submission Agent.  Placing message into the deferred queue might
yield denial of service, but we argue that it's better than a privacy
leak.

This only covers *internal messages* (from Fripost to Fripost) though:
only messages with ‘fripost.org’ (or a subdomain of such) as recipient
domain.  Other domains, even those using mx[12].fripost.org as MX, are
not covered.  A scalable solution for arbitrary domains would involve
either DANE and TLSA records, or MTA-STS [RFC8461].  Regardless, there
is some merit in hardcoding our internal policy (when the client and
server are both under our control) in the configuration.  It for
instance enables us to harden TLS ciphers and protocols, and makes the
verification logic independent of DNS.

0 files changed, 0 insertions, 0 deletions