Re: when should we esmtps our mxes?
>>>>> Ben Hutchings <ben@decadent.org.uk> writes:
>>>>> On Mon, 2016-10-24 at 15:15 +0000, Ivan Shmakov wrote:
>>>>> Ben Hutchings <ben@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.
My point is: the absence of ‘TLS’ in Received: is a cleaner
indication of the possible tampering of the message. On the
contrary, its presence in the headers and (or) MX logs may turn
to be misleading when the sending side routinely disregards the
absence of a valid signature on the certificate.
The “opportunisticity” of ESMTPS does not seem relevant.
>> 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.
It’s been argued that, as all the CAs are trusted equally (if at
all) by the user agent, it makes sense to minimize the number of
CAs trusted by any specific user – so to reduce the “attack
surface” – and, if necessary, rely on “security exceptions”
instead for the HTTPS sites that use X.509 certificates signed
by marginal (with respect to that same specific user) CAs.
Obviously, implementing RFC 6797 “No User Recourse” provision to
the letter makes that impossible. Now, given that it seems way
easier to disable HSTS support altogether in the user agent than
to patch one up to get some more sensible behavior…
That said, I see no reason there can’t be some STRICTSECURITY
EHLO keyword, analogous in function to the HSTS header.
Of course, so long as non-TLS ESMTP remains functional –
something that, unfortunately, gradually goes away for HTTP.
[…]
PS. Now, it makes me wonder, since when are we standardizing
applications to give more heed to the whims of the remote’s
administrator than to the application’s own user? Free software
used to be better than that; or so I recall.
--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Reply to: