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
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
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
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 <jtam.home at gmail.com>
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. 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.
> 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>