Le 29 mai 2020 à 11:17, Stuart Henderson stu@spacehopper.org a écrit :
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).
That’s why this RFC exists: https://tools.ietf.org/html/rfc8314 https://tools.ietf.org/html/rfc8314
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).