identify 143 vs 993 clients

[Jean-Daniel]

> Le 29 mai 2020 à 11:17, Stuart Henderson <stu at spacehopper.org> a écrit :
> 
> On 2020-05-26, mj <lists at 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).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20200529/a3b94d85/attachment.html>