• Charlie Davis, 2006-04-01 04:56:

1.0 Beta 3.

Plain authentication works. But not TLS. I don't see anything in the configuration file that seems obvious to deny TLS authentication.

You seem to have a few things mixed up here. TLS doesn't have to do anything with _authentication_, it's a _connection/encryption_ method, like SSL.

With SSL, a connection is encrypted right from the beginning. Typically, a server needs to listen on two different ports when it supports both encrypted and unencrypted connections. With IMAP, this would be 143 for unencrypted connections, and 993 for (SSL-)encrypted connections.

With TLS, a connection starts out unencrypted, and the client and server can (but don't have to) negotiate and switch to an encrypted connection on the fly, on the _same_ port, and without having to reconnect.

That's what you configure in Thunderbird under "Secure connection" - you can have "Never" (= unencrypted connection), "TLS if available" (= try to negotiate an encrypted connection via TLS, else fall back to unencrypted), "TLS" (= use TLS, don't connect if the negotiation fails) and "SSL". On Dovecot's side, the corresponding configuration option is "ssl_disable". When set to "yes", Dovecot doesn't offer TLS negotiation (the "STARTTLS" capability), and it doesn't listen for encrypted connections on port 993.

That's one thing. Now here's the second.

In addition to that, you can tell TB to "Use secure _authentication_" - that's the single checkbox under the "Secure connection" radio buttons (I'm using TB 1.5, it might look different in earlier versions). On Dovecot's side, the corresponding configuration option is "mechanisms" in the "auth" section. This controls the "AUTH=" capabilities that Dovecot offers, see http://wiki.dovecot.org/Authentication for details. So far, the only secure (ie. non "AUTH=PLAIN") method I have found that TB accepts is CRAM-MD5 (using HMAC-MD5 hashes).

Note that you can basically have any combination of secure connections and secure authentication, provided that both client and server support it. There's nothing to stop you from using CRAM-MD5 authentication over an unencrypted connection, or PLAIN authentication over SSL (a rather common thing), or NTLM authentication via TLS, or ... you name it. Granted, not all of these combinations might make sense, but you can still use them if you want.

Sorry if I was only telling you stuff you already knew up to now, but from what I've read in your mails I'm not sure if it's the connection or the authentication that is giving you problems. ;-)

Now, there really seems to be a problem with Thunderbird and using PLAIN authentication via TLS when Dovecot is set to "disable_plaintext_auth = yes" (the default).

It looks like TB only asks for capabilities _before_ the connection is encrypted. At this point, Dovecot answers "LOGINDISABLED", because the connection is not encrypted yet, and there's no way for it to know whether TB is going to issue STARTTLS later on or not. Unless TB is set to "[x] Use secure authentication", it seems to simply give up there, thinking that "AUTH=PLAIN" is not available at all.

Now, if TB would just go ahead with the TLS negotiation, and then ask for capabilities again once the connection is encrypted, Dovecot would now answer "AUTH=PLAIN" instead of "LOGINDISABLED", and TB would be able to authenticate just fine. Alas, this doesn't happen.

There's no such problem when using SSL instead of TLS. With SSL, Dovecot offers "AUTH=PLAIN" even with "disable_plaintext_auth = yes", and TB can authenticate just fine, no matter whether "[x] Use secure authentication" is enabled or not.

To summarize, Dovecot with "disable_plaintext_auth = yes" and Thunderbird configured with ...

... secure connection = SSL, secure authentication = yes: works ... secure connection = SSL, secure authentication = no: works ... secure connection = TLS, secure authentication = yes: works ... secure connection = TLS, secure authentication = no: FAILS

When running Dovecot with "disable_plaintext_auth = no", the last variant works as well.

Note that I haven't done any detailed analysis (source code, packet sniffing) on this matter, but from what I've seen in Dovecot's logs with auth_verbose, auth_debug and auth_debug_passwords, this seems to be the problem.

I also haven't done any RFC digging, so I don't know if this is TB's problem or Dovecot's. Is it okay for an IMAP server to first advertise "LOGINDISABLED", and then, after a successful TLS negotiation, change its mind and offer "AUTH=PLAIN"? Is it okay for an IMAP client to assume "AUTH=PLAIN" is not available at all if it sees "LOGINDISABLED", and to not even bother to "STARTTLS" and try again? The example in RFC3501 section 6.1.1. would suggest that Dovecot is right and TB is wrong, but, as I said, I haven't done any more detailed digging.

Thomas

=-------------------------------------------------------------------------=

• Thomas "ZlatkO" Zajic <zlatko@gmx.at> Linux-2.6.16 & Thunderbird-1.5 -

• "It is not easy to cut through a human head with a hacksaw." (M. C.) -