On Mon, 2016-10-24 at 15:15 +0000, Ivan Shmakov wrote: > > > > > > > > > > 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’.
Although that's mitigated by HSTS and bookmarking of https: URLs. > 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.) Of course you can do this on a smarthost; I do the same. I don't see how that's relevant to lists.debian.org. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong.
signature.asc
Description: This is a digitally signed message part
