Thanks Andy: I've also found it a bit confusing with different client settings.
To the original problem: I removed now DIGEST-MD5 from my auth mechanisms, restarted and all seems fine. Thanks Eric! Best, Peter On Tue, Aug 14, 2018 at 7:42 PM, Andrew Swartz <[email protected]> wrote: > My understanding is that RFC compliance is highly variable in email > client-server relationships. This is because servers tend to have > preexisting relationships with clients such that servers can dictate > configurations. Therefore RFC compliance isn't important for > interoperability. > > Using STARTTLS over port 143 is perfectly secure if it is "required." > > The pertinent RFC's is 2595 (June 1999), which I just reviewed. It > specifies (and favors) STARTTLS on port 143 and frowns upon the dedication > of port 993 for TLS. The exact wording is: '*Separate ports imply a model > of either "secure" or "not secure."*' It is interesting that that > concept was frowned upon back then because it has definitely become favored > today. Being in a nebulous/unknown security state leads to false > assumptions which lead to security failure. > > So per the RFC, I stand corrected: port 143 is the designated STARTTLS > port. That makes logical since because the initial handshakes of TLS and > STARTTLS are incompatible, whereas plain-text and STARTTLS both start out > the same. However, going as far back as using Eudora in the late 90's, > I've seen massive variability in IMAP/POP configurations. When the server > gets to dictate configuration to the client in advance, anything goes. > > For example, here is Thunderbird's port 993 options: > > > > > Note that STARTTLS is an option on 993 (along with "none") and that there > is no setting for "required" versus "optional". I've been using > Thunderbird for about 10 years, and I'm pretty sure that prior versions had > a setting for "required" or "optional" for STARTTLS. Eudora definitely had > it. There is a reasonable chance that the Thunderbird developers removed > the setting and that it silently uses "required". But if so, the end > result is an ambiguous security setting from the perspective of > admins/users. That is currently unacceptable. The IMAP/POP server might > be configured for required STARTTLS, but how would the user know that? > Transparency = good, ambiguity = bad. > > > That being said, here is Thunderbird's setting for submission on port 465: > > > > Clearly "None" and "STARTTLS" are not supposed to be supported on port > 465. I imagine they include those options because enough server admins > want them. Again, the clients simply do as their server admins dictate. > > Good question because it prompted me to review the RFC's. > > The password encryption schemes (like digest-md5) are a concept which > predates authentication over an encrypted channel. The problem with > digest-md5 is that the md5 hash is considered broken and completely > insecure for such purposes. The new mantra is to be explicitly secure or > insecure; therefore use of weak security to achieve a nebulous security > situation is slowly becoming outlawed. Here is the wikipedia article about > digest-md5: https://en.wikipedia.org/wiki/Digest_access_authentication > > If you can guarantee an encrypted session (which is always the case with > TLS), then just use PLAIN auth and ignore the password encryption schemes > all together. The advantage of this is that PLAIN will never require > reconfiguration because it has become "broken". > > Again, I hope with is helpful (and accurate). > > -Andy > > > > > > > > > > > On 8/14/2018 1:10 AM, Peter Peltonen wrote: > > Thanks Andy. Just to be sure on this: I had the impression that > STARTTLS could be used also with port 143? At least > readinghttps://wiki.dovecot.org/SSL indicates so: > > "Clients using STARTTLS work by connecting to the regular unencrypted > port and immediately issue a STARTTLS command, after which the session > is encrypted." > > So it shouldn't matter if I use 143 or 993 as a port? > > My users should all use TLS (configured to their clients). I'm still > wondering about the DIGEST-MD5: what is that auth mechanism for and > why did my toaster conf use it? Anything bad that can happen by > removing it? And what is the difference between PLAIN and LOGIN auth > mechanisms? Are there client configs For Outlook / Thunderbird / Apple > Mail that could be broken by this? > > Best, > Peter > > > > On Tue, Aug 14, 2018 at 11:25 AM, Andrew Swartz <[email protected]> > <[email protected]> wrote: > > Peter, > > If you are using ports 110/143, which are clear-text, then you should > switch to 993/995 (if possible, of course). > > Ports 993/995 are never intentionally clear-text; they are either TLS or > STARTTLS. Many servers/clients can be configured for either, but they > cannot be configured for both because the initial protocol sequences are > incompatible. > > If 993/995 are configured for TLS, you can use PLAIN auth method and not > give it another thought. > > But if configured for STARTTLS, it must be set to "require" STARTTLS > rather than just "if available". If you can "require" STARTTLS, then > PLAIN auth is secure because the login cannot not be sent unencrpyted. > > But if the connection is configured as "STARTTLS if available", then > failure to initiate the STARTTLS will result in continuing with a clear > text session. In this scenario, a PLAIN auth would be very dangerous. > > Hope this helps. > > -Andy > > > On 8/13/2018 11:43 PM, Peter Peltonen wrote: > > Thanks for the suggestions! > > So if I have only plain and login auth mechanisms enabled, what does > that mean in practice security wise? > > Any ideas why the error is happening sometimes but not always and why > aut_cache settings would fix the problem? Is it related to caching > credentials for different devices / clients for same account? > > Best, > Peter > > On Tue, Aug 14, 2018 at 5:52 AM, Eric Broch <[email protected]> > <[email protected]> wrote: > > I'd remove DIGEST-MD5 from 'auth_mechanisms'. > > > > On 8/13/2018 3:01 PM, Peter Peltonen wrote: > > I have a user with Outlook 2016 having this error appearing in the > Dovecot logs and not being able to login when it occurs > > The strange thing is that if I restart dovecot then the Outlook can > login and no error: > > method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS > > What I have for auth mechanisms in toaster.conf is: > > auth_mechanisms = plain login digest-md5 > > I thought it was a dovecot cache issue and I changed > > cache_key=%u > > to > > cache_key=%u%r > > but the problem reappeared after a week. > > This is an old QMT installation on COS5. > > Best, > Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- > Eric Broch > White Horse Technical Consulting (WHTC) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- > Andrew W. Swartz, MD > Departments of Emergency Medicine, Family Medicine, and Surgery > Yukon-Kuskokwim Delta Regional Hospital > Bethel, Alaska > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- > Andrew W. Swartz, MD > Departments of Emergency Medicine, Family Medicine, and Surgery > Yukon-Kuskokwim Delta Regional Hospital > Bethel, Alaska > >
