On Tue, 26 May 2020, mj wrote:
On 25/05/2020 23:04, Voytek wrote:
jumping here with a question, if I use 143 with STARTTLS, and, force
TLS/SSL in configuration, that's equivalent from security POV, isn't
it? and, same for 110 STARTTLS? Or am I missing something?
There's an important clause here that often becomes overlooked: "force
TLS/SSL in [client] configuration". If you don't fulfil this condition,
STARTTLS can fall prey to downgrade attacks. This has been done, and
not by small players:
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
Some mail readers, like macOX Mail, will happily reconfigure your mail reader
server settings to use plaintext unless you disable it.
Interesting point, after some googling, I think you are right, and as long as
we have set "disable_plaintext_auth = yes" (and we have that) we should be
fine keeping 143 open. Right?
Yes, provided the above condition is met. However, unless you control
all endpoints, that's hard to enforce.
One doubt I had: "disable_plaintext_auth = yes" sounds as if only the
authentication part is secured, and the rest is kept plain text, whereas with
993/SSL, *everything* would be encrypted?
Once STARTTLS negotiations are over, it is equivalent to SSL: all data
is encrypted. However, I see your point: the configuration label suggests
it's limited to authentication data, as opposed to all data. Something
like "ssl_forbid_decline" or "ssl_not_optional" might have been clearer.
Joseph Tam <jtam.h...@gmail.com>
