|author||Guilhem Moulin <firstname.lastname@example.org>||2021-01-26 12:39:10 +0100|
|committer||Guilhem Moulin <email@example.com>||2021-01-26 13:35:40 +0100|
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.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.
Diffstat (limited to 'certs/public/fripost.org.pub.back')
0 files changed, 0 insertions, 0 deletions