On 2020-05-26, mj <
lists@merit.unu.edu> wrote:
Hi,
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?
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?
In the case of 143, nothing stops the client *sending* a plaintext login
request. Login may be denied, but the password is already leaked. Also
if you have only the server side (not the client side) deny plaintext
logins, a MITM can just strip off the STARTSSL capability from the server
response.
And doing that it can as easily inject a LOGIN capability, making non-broken client also send the password in plain text. (Only broken client will send password if LOGIN is not present).
In a setting where you want to protect the clients from accidentally
exposing secrets by misconfiguration, allowing only 993/995 (and 465 for
SMTP; 25/587 have the same problem) is the safe way.
Port 25 is a special case and should never be used by client, but only for (unauthenticated) server to server communication.
There is no way to use implicit TLS for SMTP as the SMTP transport MX infrastructure has no way to specify a port.
Client should always use the submission port (587, or 465 for submission over TLS).