identify 143 vs 993 clients

mj lists at merit.unu.edu
Fri May 29 14:27:19 EEST 2020


Thanks to all who participated in the interesting discussion.

It seems my initial thought might have been best after all, and 
discontinuing port 143 might be the safest way proceed.

Thanks again, valuable insights!

MJ

On 5/29/20 11:48 AM, Jean-Daniel wrote:
> 
> 
>> Le 29 mai 2020 à 11:17, Stuart Henderson <stu at spacehopper.org 
>> <mailto:stu at spacehopper.org>> a écrit :
>>
>> On 2020-05-26, mj <lists at merit.unu.edu <mailto: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
> 
>> 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).
> 
> 


More information about the dovecot mailing list