324138 - fails to login to IMAP server if IMAP server requires STARTTLS and advertises LOGINDISABLED before STARTTLS is issued

Status: RESOLVED DUPLICATE of bug 312009

(Thunderbird :: Security, defect)

Description

[Schley Andrew Kutz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I configured Courier-IMAP to require the use of TLS.  Doing so makes Courier-IMAP issue LOGONDISABLED prior to the client issuing a STARTTLS.  Thunderbird sees the LOGONDISABLED and even it if issues a STARTTLS, it will immediately LOGOUT.  Thunderbird then pops up a messagebox saying that the server has disabled logons.

Reproducible: Always

Steps to Reproduce:
1. Configure Courier-IMAP to require TLS over port 143
2. Try logging in with Thunderbird with TLS to see it fail.
3. Don't require TLS on the server.
4. Try logging in with Thunderbird wiht TLS to watch it succeed.

Actual Results:  
I can't login with this log:

Jan 20 08:16:40 akutz imaplogin: Connection, ip=[::ffff:24.155.176.246]
Jan 20 08:16:40 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=STARTTLS
Jan 20 08:16:40 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=CAPABILITY
Jan 20 08:16:42 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=LOGOUT
Jan 20 08:16:42 akutz imaplogin: LOGOUT, ip=[::ffff:24.155.176.246]

Expected Results:  
When I don't require TLS (but use it anyway) I can login and here is the log:

Jan 20 08:19:46 akutz imaplogin: Connection, ip=[::ffff:24.155.176.246]
Jan 20 08:19:46 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=CAPABILITY
Jan 20 08:19:46 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=STARTTLS
Jan 20 08:19:46 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=CAPABILITY
Jan 20 08:19:50 akutz imaplogin: LOGIN: DEBUG: ip=[::ffff:24.155.176.246], command=AUTHENTICATE
Jan 20 08:19:50 akutz imaplogin: authdaemon: starting client module
Jan 20 08:19:50 akutz authdaemond.plain: received auth request, service=imap, authtype=login
Jan 20 08:19:50 akutz authdaemond.plain: authpam: trying this module
Jan 20 08:19:50 akutz authdaemond.plain: authpam: sysusername=akutz, sysuserid=<null>, sysgroupid=1000, homedir=/home/ak
utz, address=akutz, fullname=Schley Andrew Kutz,,,, maildir=<null>, quota=<null>, options=<null>
Jan 20 08:19:50 akutz authdaemond.plain: pam_service=imap, pam_username=akutz
Jan 20 08:19:50 akutz authdaemond.plain: dopam successful
Jan 20 08:19:50 akutz authdaemond.plain: authpam: ACCEPT, username akutz

Thunderbird 1.5
Courier-IMAP 3.08-3ubuntu7.1
Courier-IMAP-SSL 3.08-3ubuntu7.1

Comment 1

[Kai Germaschewski]

I can confirm the same problem when connecting to Cyrus-imap.

Comment 2

[Thomas Zajic]

Same problem here using Dovecot-1.0beta3. TLS works fine if I also enable "Use secure authentication", but fails if I disable it:

[zlatko@disclosure]:~$ NSPR_LOG_MODULES=IMAP:5 NSPR_LOG_FILE=$PWD/xxx thunderbird
[zlatko@disclosure]:~$ grep 8d0b9d8 xxx
-1487632704[807d9f8]: 8d0b9d8:imap:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
-1546212432[8bffa60]: ImapThreadMainLoop entering [this=8d0b9d8]
-1546212432[8bffa60]: 8d0b9d8:imap:NA:ProcessCurrentURL: entering
-1546212432[8bffa60]: 8d0b9d8:imap:NA:ProcessCurrentURL:imap://user@host:143/select%3E.INBOX:  = currentUrl
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: * OK Dovecot ready.
-1546212432[8bffa60]: 8d0b9d8:imap:NA:SendData: 1 capability
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=DIGEST-MD5 AUTH=CRAM-MD5
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: 1 OK Capability completed.
-1546212432[8bffa60]: 8d0b9d8:imap:NA:SendData: 2 STARTTLS
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now.
-1546212432[8bffa60]: 8d0b9d8:imap:NA:SendData: 3 capability
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: 3 OK Capability completed.
-1546212432[8bffa60]: 8d0b9d8:imap:NA:ProcessCurrentURL: aborting queued urls
-1546212432[8bffa60]: 8d0b9d8:imap:NA:SendData: 4 logout
-1546212432[8bffa60]: 8d0b9d8:imap:NA:CreateNewLineFromSocket: * BYE Logging out
-1546212432[8bffa60]: 8d0b9d8:imap:NA:TellThreadToDie: close socket connection
-1546212432[8bffa60]: ImapThreadMainLoop leaving [this=8d0b9d8]
[zlatko@disclosure]:~$

So, basically the sequence of events looks like this:

- TB asks for capabilities,
- sees "STARTTLS LOGINDISABLED",
- successfully negotiates TLS,
- asks for capabilities again,
- sees "AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5",
- and then logs out instead of using "AUTH=PLAIN" - why?

Running on Linux, TB-1.5.0.2 compiled from sources (TB-1.5 had the same problem, but TB-1.5beta1 worked fine according to a post on the dovecot mailing list: http://dovecot.org/list/dovecot/2006-April/012802.html).

Comment 3

[eric]

Note that it works fine in Thunderbird 3.0 Alpha 1 builds, at least as of today's nightly (20060506).  So at least one of the developers probably knows what the problem was and how it was fixed.  It would be nice to get the fix backported to 1.5.0.x, because I really don't want to tell my users that they should use a nightly build.

Comment 4

[Thomas Zajic]

Woop, seems like this finally got fixed here: https://bugzilla.mozilla.org/show_bug.cgi?id=312009 - thanks! :-)

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Reporter (Schley): Can you confirm this is fixed in recent nightly builds?

Perhaps this is a duplicate of bug 312009 (which David fixed), as Thmoas 
suggested above.

Comment 6

[Thomas Zajic]

Seems like this is/was indeed a duplicate of bug 312009. Just tested again with TB 1.5.0.5 and Dovecot-1.0.rc7, works fine now.

Comment 7

[David :Bienvenu]

ok, thx, resolving as dup. I'm not 100% sure it's the right dup, but there have been several issues fixed - a couple of the other fixes will be in the next 1.5.0.x release

*** This bug has been marked as a duplicate of 312009 ***