[Dovecot] Quick question. Thunderbird/Outlook = no love.

[Thomas Zajic]

* 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 at gmx.at>   Linux-2.6.16 & Thunderbird-1.5 -
-  "It is not easy to cut through a human head with a hacksaw."  (M. C.)  -
=-------------------------------------------------------------------------=