Hi Victor… Thanks so much for the feedback…very helpful…
I’ve always been dubious about the auth requirement by some (i.e. the brain deads to which you refer) to allow TLS connections for server-to-server communications. My view is this — when my server sends outbound mail, do I really care that the server I looked up via DNS is who they purport to be in the cert? I have to imagine if a bad actor is able to somehow hack\forge DNS records that they will also be able to take care of the cert especially given that LE is free and very easy to obtain after the DNS has been cfg’d. In any event, people do what people do so I guess in order to ensure my server will employ the highest number of TLS sessions, I should use a CA-signed cert... Agreed? > On Jul 25, 2020, at 8:03 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> > wrote: > > On Sun, Jul 26, 2020 at 02:45:38AM +0000, Antonio Leding wrote: > >> My goal is to fully understand what is lost by using only self-signed >> certs on my PF server. Here’s what I think I know: >> >> — The fact that the cert is self-signed really only impacts mail >> coming into our organization from those who are outside the >> organization. > > Assuming that no internal system fails to implement opportunistic TLS in > a sane manner. > >> — Because the cert cannot be verified, only anonymous ciphers can be >> negotiated between my server and the other side’s client. > > No. that's false. A majority of clients will solicit certificates they > then proceed to ignore. It's to some extent a cargo-cult thing, someone > on the Internet said that anonymous ciphers are insecure, and so users > avoid them, though they don't exactly know why. But the sickness is > deep, TLS 1.3 has completely removed support for anonymous ciphers, so > in a few years their use will be rather exotic. > >> I have to believe there are more considerations here which of course >> is why I came to you all… > > A few brain-dead bulk mail systems (you probably don't care about), > abort the TLS handshake when they see a certificate chain they can't > verify, and then proceed to deliver in clear text, as though that's more > secure than using unauthenticated TLS. Again cargo-cult, someone on the > Internet said that certificate verification is not optional. > > Otherwise, you're free to use self-signed certs, they work just fine for > quite a lot of receiving systems. > > You can even implement DNSSEC for your domain (with monitoring to > check that it is working, that signatures are not too close to > expiration, ...) and then publish DANE TLSA records: > > https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources > > but again only if you also implement monitoring to ensure that > the certificate chain and TLSA records match, and a cert rollover > process that avoids periodic outages caused by rolling the cert > and TLSA RRs at the same time and ignoring remote caches, and/or > older authoritative zone data on secondary servers. > > -- > Viktor.
