On 2022/08/03 14:01, Jarland Donnell via mailop wrote: > > The MTA-MTA encryption is weak at best: because the client doesn't > > (can't, actually) verify that the certificate is appropriate for that > > MTA, any MITM attack is easily accomplished. End users get virtually no > > indication that the message was or wasn't encrypted in transit, and > > there is no accepted mechanism to force encryption in the first place. > > Why can't an MTA verify a certificate? Postfix seems to do certificate > verification, for example: > https://www.postfix.org/TLS_README.html#server_vrfy_client
That's talking about client certificates which is a different matter than the client verifying the server's certificate. I think when acting as SMTP-over-TLS clients, most MTAs out there are not checking the server's certificate in any really meaningful way; they can usually be configured to do so but, last time I looked, there were plenty of expired certs, mismatching host names, and self-signed certs, and based on what I've seen with web servers I'd expect to see more than a few with valid CA-signed certs, but with no chain cert presented. Turning this on for general use (rather than for specific destinations) would seem likely to result in a lot of failures. Without cert verification, there seems little point in requiring stronger TLS versions. Rather than trying to break a weaker encryption protocol (usually still relatively hard) an attacker could MITM with their own cert. FWIW https://www.postfix.org/TLS_README.html#client_tls_verify shows how to enable this for Postfix, but very much recommends against it on the internet for now. _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
