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 <awswa...@acsalaska.net>
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 <awswa...@acsalaska.net> 
> <awswa...@acsalaska.net> 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 <ebr...@whitehorsetc.com> 
> <ebr...@whitehorsetc.com> 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: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
> --
> Eric Broch
> White Horse Technical Consulting (WHTC)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>  --
> Andrew W. Swartz, MD
> Departments of Emergency Medicine, Family Medicine, and Surgery
> Yukon-Kuskokwim Delta Regional Hospital
> Bethel, Alaska
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>
> --
> Andrew W. Swartz, MD
> Departments of Emergency Medicine, Family Medicine, and Surgery
> Yukon-Kuskokwim Delta Regional Hospital
> Bethel, Alaska
>
>

Reply via email to