Re: identify 143 vs 993 clients

[Joseph Tam]

On Sun, 31 May 2020, Jean-Daniel wrote:


So yes the safest way to go is to just use port 993, but as long as
the client is not set to a "TLS if available" option then port 143 is
also safe.


I don?t think you can call an option safe if it relies on the users to
properly configure their client.  We all know that users are usually
bad at following instructions ;-)


I think Peter nailed it, but let's put it this way: the server policy
is irrelevant to client side policy.  *If* the client has been not been
configured to disable plaintext password, a malicious party can coax
a password out of a client, despite what the server policy is, or even
whether the server is available.

Only allowing implicit SSL will guarantee insecurely configured clients
will fail (and maybe not even that if it autoconfigures), but it doesn't
prevent them from being exploited.

Joseph Tam 

Re: identify 143 vs 993 clients

[Peter]

On 31/05/20 6:50 pm, Jean-Daniel wrote:

Yes and no.  Some of the attack vectors mentioned are not reasonable and it really depends on the 
client.  Thunderbird, for example, used to have settings for plain text, TLS and "TLS if 
available", but the latter setting has not been available for some time which forces the user 
to choose either plain text or TLS at setup time now.  This means that the user would now have to 
change the setting in their client for a downgrade attack to work.  I can't speak for all MUAs but 
if they similarly have removed their "TLS if available" option or if the users explicitly 
don't pick that option (you can ask them not to in your setup instructions) then that type of 
downgrade attack cannot occur.

The other possible downgrade attack which was not mentioned but is equally 
mitigated by the client is where the MITM intercepts the connection, connects 
to your server and issues a STARTTLS itself but presents the resulting 
connection as plain text to the client.  This means that enforcing STARTTLS on 
the server side will not prevent a plain text connection through a MITM from 
the client.  But do keep in mind that if the client is configured properly to 
only connect via TLS then it will refuse the connection if it is not presented 
with a STARTTLS option that works.

So yes the safest way to go is to just use port 993, but as long as the client is not set 
to a "TLS if available" option then port 143 is also safe.


I don’t think you can call an option safe if it relies on the users to properly 
configure their client. We all know that users are usually bad at following 
instructions ;-)


Fair enough, but this attack vector can only happen if it's on a client 
that supports a downgrade option (I should hope that most don't 
nowadays, but someone did mention MacOX Mail earlier) *and* the user 
selects that option when configuring as opposed to the stricter "TLS 
only" (or equivalent) option.  At that point it still requires a MITM 
attack to downgrade the connection, and that MITM must not only be able 
to read the packets but also intercept them and present different data 
to the user.  I can see this type of attack happening in wifi 
environments and coming from ISPs that want to snoop on people's email, 
though.


As I said (and I stand by it) the safest approach is to just limit to 
port 993, but port 143 is also safe if properly configured on both the 
server and client side.



Peter

Re: identify 143 vs 993 clients

[Jean-Daniel]

> Le 31 mai 2020 à 06:09, Peter  a écrit :
> 
> On 29/05/20 11:27 pm, mj wrote:
>> 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.
> 
> Yes and no.  Some of the attack vectors mentioned are not reasonable and it 
> really depends on the client.  Thunderbird, for example, used to have 
> settings for plain text, TLS and "TLS if available", but the latter setting 
> has not been available for some time which forces the user to choose either 
> plain text or TLS at setup time now.  This means that the user would now have 
> to change the setting in their client for a downgrade attack to work.  I 
> can't speak for all MUAs but if they similarly have removed their "TLS if 
> available" option or if the users explicitly don't pick that option (you can 
> ask them not to in your setup instructions) then that type of downgrade 
> attack cannot occur.
> 
> The other possible downgrade attack which was not mentioned but is equally 
> mitigated by the client is where the MITM intercepts the connection, connects 
> to your server and issues a STARTTLS itself but presents the resulting 
> connection as plain text to the client.  This means that enforcing STARTTLS 
> on the server side will not prevent a plain text connection through a MITM 
> from the client.  But do keep in mind that if the client is configured 
> properly to only connect via TLS then it will refuse the connection if it is 
> not presented with a STARTTLS option that works.
> 
> So yes the safest way to go is to just use port 993, but as long as the 
> client is not set to a "TLS if available" option then port 143 is also safe.

I don’t think you can call an option safe if it relies on the users to properly 
configure their client. We all know that users are usually bad at following 
instructions ;-)

Re: identify 143 vs 993 clients

[Peter]

On 29/05/20 11:27 pm, mj wrote:

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.


Yes and no.  Some of the attack vectors mentioned are not reasonable and 
it really depends on the client.  Thunderbird, for example, used to have 
settings for plain text, TLS and "TLS if available", but the latter 
setting has not been available for some time which forces the user to 
choose either plain text or TLS at setup time now.  This means that the 
user would now have to change the setting in their client for a 
downgrade attack to work.  I can't speak for all MUAs but if they 
similarly have removed their "TLS if available" option or if the users 
explicitly don't pick that option (you can ask them not to in your setup 
instructions) then that type of downgrade attack cannot occur.


The other possible downgrade attack which was not mentioned but is 
equally mitigated by the client is where the MITM intercepts the 
connection, connects to your server and issues a STARTTLS itself but 
presents the resulting connection as plain text to the client.  This 
means that enforcing STARTTLS on the server side will not prevent a 
plain text connection through a MITM from the client.  But do keep in 
mind that if the client is configured properly to only connect via TLS 
then it will refuse the connection if it is not presented with a 
STARTTLS option that works.


So yes the safest way to go is to just use port 993, but as long as the 
client is not set to a "TLS if available" option then port 143 is also safe.


Also note that the same concerns apply for your submission server 
(likely postfix) using the submission port (587) and enforcing STARTTLS 
vs the submissions port (465) which is a direct TLS connection.



Peter

Re: identify 143 vs 993 clients

[@lbutlr]

On 25 May 2020, at 12:48, mj  wrote:
> I would then ask them to move over to 993, and finally disable port 143 
> altogether.

From personal experience the only way to do this is to stop listening to port 
143. I dropped support for non-encrypted mail ports ages ago, and I didn't get 
a single user to switch from 143 to 993 until I disabled 143.

Send an email to your users "You must make this change bu (date+2 days)" and 
then drop port 143 in 2 days as promised. If you have a web server, but a large 
red box on it "Can't login?" With a link to the email you sent.

(And do not allow users to send mail un-encrypted either, force them to use 587 
or 465 by not accepting user mail on port 25).



-- 
This is Art holding a Mirror up to Life. That's why everything is
exactly the wrong way around. --Wyrd Sisters

Re: identify 143 vs 993 clients

[mj]

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 > a écrit :


On 2020-05-26, mj mailto:li...@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).

Re: identify 143 vs 993 clients

[Jean-Daniel]

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

Re: identify 143 vs 993 clients

[Stuart Henderson]

On 2020-05-26, mj  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.

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.

Re: identify 143 vs 993 clients

[Joseph Tam]

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 

Re: identify 143 vs 993 clients

[mj]

Hi Markus,

Thank you very much.

MJ

On 26/05/2020 10:25, Markus Winkler wrote:

Hi,

On 26.05.20 09:21, mj wrote:
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?


Or am I missing something? (then perhaps someone can point it out?)


here you can read the details:

https://doc.dovecot.org/admin_manual/ssl/dovecot_configuration/

"There are a couple of different ways to specify when SSL/TLS is required:
[...]"

Regards,
Markus

Re: identify 143 vs 993 clients

[Markus Winkler]

Hi,

On 26.05.20 09:21, mj wrote:
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?


Or am I missing something? (then perhaps someone can point it out?)


here you can read the details:

https://doc.dovecot.org/admin_manual/ssl/dovecot_configuration/

"There are a couple of different ways to specify when SSL/TLS is required:
[...]"

Regards,
Markus

Re: identify 143 vs 993 clients

[mj]

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?


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?


Or am I missing something? (then perhaps someone can point it out?)

Thanks,
MJ

Re: identify 143 vs 993 clients

[Voytek]

On 26 May 2020 4:48:51 AM AEST, mj  wrote:

>I would then ask them to move over to 993, and finally disable port 143 
>altogether.
>

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?

thanks,
V
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: identify 143 vs 993 clients

[mj]

On 25/05/2020 20:52, Aki Tuomi wrote:


You could use

https://doc.dovecot.org/settings/core/#login-log-format-elements

to log this.



Yes! Perfect!

Thanks! :-)

Re: identify 143 vs 993 clients

[Aki Tuomi]

> On 25/05/2020 21:48 mj  wrote:
> 
>  
> Hi,
> 
> I am trying to find a nice way to identify dovecot clients that are 
> still configured to use port 143 to connect to our mailserver, from the 
> dovecot logs.
> I would then ask them to move over to 993, and finally disable port 143 
> altogether.
> 
> When looking at the dovecot logs, it seems this is not logged in any 
> obvious way.
> 
> Of course I could use netflow etc, but that would not give us usernames, 
> but IP's, etc.
> 
> So, is there a nice way to somehow indicate in the dovecot logs, if a 
> client connected on 143 or on 993?
> 
> Thanks!

You could use

https://doc.dovecot.org/settings/core/#login-log-format-elements

to log this.

Aki