[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: