> 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>
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). > >
Hi, I want to do a simple backup of my maildir. I read here that maildirlock is not to count on in the future and the recommended option was to use doveadm backup. However, it seems that this requires to setup another dovecot server. My questions are: - How much to I need to configure this new server? Do I need to setup user by user, or even install postfix (that's where my users are configured) to get it all backed up? I tried to install dovecot and running doveadm backup, but it complains the users are not there. - What's the simplest way to configure dovecot without mirrowing my server so that this can work? Best, Francis --- Francis Augusto Medeiros-Logeay Oslo, Norway
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