> On Dec 11, 2017, at 8:55 PM, J Doe <gene...@nativemethods.com> wrote: > >> The recommended set of trusted CAs for the Postfix SMTP client is >> *empty*. TLS in SMTP is opportunistic, and email sent whether or >> not the peer appears to be authenticated. So any trusted CAs you >> might configure are largely just wasted memory and CPU. > > Ok. If I am understanding you correctly, you are saying that if the SMTP > client is configured to use opportunistic TLS, the mail will be delivered > regardless of whether the remote peer is *authenticated*?
Correct, and indeed with Opportunistic TLS Postfix does not attempt to check the peer hostname against any names in the certificate. And so, even if the certificate chain is issued by a trusted CA, it may well be for some unrelated hostname. > In my case, I use opportunistic TLS for the SMTP client: > > /etc/postfix/main.cf > smtp_tls_security_level = may > > I then had the CA list set up: > > /etc/postfix/main.cf > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > I did not have any per-destination rules set up - all mail via the > SMTP client used these settings. When I send a test message in to > my server and the SMTP client sends it out to my test Gmail address, > I note that the TLS log line in mail.log is: > > Dec 11 20:40:44 server postfix/smtp[2559]: Trusted TLS connection . . . > > But when I remove the CA list the log line is: > > Dec 11 20:40:44 server postfix/smtp[2559]: Untrusted TLS connection . . . > > *HOWEVER* you are saying that the authentication status (“Trusted” / > “Untrusted”), is actually irrelevant as the mail will still be delivered > to Gmail regardless. Correct. > The fact that I receive successful authentication (“trusted”), is > irrelevant compared to no authentication (“untrusted”), because the > mail goes through either way so in effect all I am doing is wasting > compute resources? Essentially, yes. Some might argue that there's forensic value in the logs, and that this type of "tamper-evidence" might even deter some kinds of attacks. I remain skeptical about that. So for most users, an empty CA list works just fine, and you get to STARTTLS to protect against passive monitoring, while remaining vulnerable to active attacks. See https://tools.ietf.org/html/rfc7435 for my views of opportunistic security. See also: http://www.postfix.org/TLS_README.html#client_tls_dane https://tools.ietf.org/html/rfc7672#section-1.3 A small, but growing fraction of SMTP domains (currently ~175k domains out of ~5.1 million DNSSEC-signed domains I've been able to find) have deployed DNSSEC and have TLSA records for their MX hosts. You can enable DANE outbound in your SMTP client, and get authenticated email delivery to these domains, with mail deferred when authentication fails (either due to an actual MiTM attack, or operational error on the receiving side). At present ~177 of the 175k domains are affected by what appear to be operational issues, this number fluctuates as errors are fixed, with a floor around ~130 domains that don't receive or ignore failure notices. Deploying DANE inbound (publishing TLSA records for your own MX hosts) requires some operational discipline. This coordinated changes in the DNS and SMTP configurations when server keys and/or certificates change: http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 When updating the certificate chain you need to temporarily pre-publish multiple TLSA records matching the current and future certificate: https://dane.sys4.de/common_mistakes#3 However, with "3 1 1" + "2 1 1", the rollover process can be substantially simplified: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html -- Viktor.
