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.
