>>>>> Ben Hutchings <b...@decadent.org.uk> writes:
[…]
> Those certificates look as expected. Since TLS encryption of SMTP
> between servers is opportunistic, there's no particular reason to use
> a widely trusted CA for server certificates. A MITM can just as
> easily block STARTTLS as substitute their own key.
That’s not necessarily any different to the HTTP(S) case.
For instance, when the user first uses ‘example.com’ as the
resource identifier, the Web user agent (usually) issues a GET
request to the said host’s HTTP server in the plain. At which
point the server responds with a 302 redirect, pointing to the
resource proper (say, https://example.com/.)
That behavior is hardly any less opportunistic, and is prone to
the very same attack, as demonstrated by ‘sslstrip’.
Yet, I’d find that quite an uncommon reason to argue that we
don’t need some widely trusted CAs for the HTTPS certificates.
On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’
files that contain the list of CNs of the remotes the MTA
permits relaying mail from (that is: acts as a smarthost for.)
Hence, TLS becomes rather mandatory in this case. (Although I
have to admit that I don’t currently apply this approach in the
“downstream” direction with any consistency.)
--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
