317540 - After TLS session has been established, TB does not send LOGIN if login was disabled

Status: RESOLVED DUPLICATE of bug 312009

(Thunderbird :: General, defect)

Description

[Luigi D. Sandon]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Maxthon; .NET CLR 1.1.4322)
Build Identifier: version 1.5 (20051025)

I'm using Mercury/32 4.01b as my IMAP server. If I disable plain-text logins (LOGINDISABLED) and enable TLS, TB correctly starts the TLS session, but after the second CAPABILITY response, which no longer contains the LOGINDISABLED capability, it does not try to send a LOGIN command to login, instead logs out.
The session was encrypted, and it would have been safe to use LOGIN.
Also, RFC 3105 requires the client to discard any cached CAPABILITY information received before the TLS session has been established.


Reproducible: Always

Steps to Reproduce:
1. Set a Mercury/32 server to refuse plain-text login but for TLS connections
2. Set up TB to connect using TLS
3. Try to connect.

Actual Results:  
TB returns the error: "You cannot login to <mail server> because the server has disabled login. You may need to connect via SSL or TSL".


Expected Results:  
It should have logged in.

Here a server log:
-------------------
22:34:43.880: Connection from 192.168.200.10, Mon Nov 21 22:34:43 2005<lf>
22:34:43.890: << * OK mail.sandon.it IMAP4rev1 Mercury/32 v4.01b server ready.<cr><lf>
22:34:43.910: >> 1 capability<cr><lf>
22:34:43.920: << * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED 
X-MERCURY<cr><lf>
22:34:43.920: << 1 OK CAPABILITY complete.<cr><lf>
22:34:43.930: >> 2 STARTTLS<cr><lf>
22:34:43.930: << 2 OK Begin SSL/TLS negotiation now.<cr><lf>
22:34:43.000: [*] SSL/TLS session established: 3DES, CBC mode, keysize 192 
bits
22:34:43.010: >> 3 capability<cr><lf>
22:34:43.010: << * CAPABILITY IMAP4rev1 X-MERCURY<cr><lf>
22:34:43.010: << 3 OK CAPABILITY complete.<cr><lf>
22:34:46.696: >> 4 logout<cr><lf>
22:34:46.696: << * BYE IMAP4rev1 Server closing connection.<cr><lf>
22:34:46.696: << 4 OK Unauthenticated LOGOUT complete.<cr><lf>
22:34:46.706: --- Connection closed normally at Mon Nov 21 22:34:46 
2005. ---
22:34:46.706:
----------------

If I allow plain-text login on the server, but leave TLS enabled on both server and client:
-----------------
22:43:01.377: Connection from 192.168.200.10, Mon Nov 21 22:43:01 2005<lf>
22:43:01.377: << * OK mail.sandon.it IMAP4rev1 Mercury/32 v4.01b server 
ready.<cr><lf>
22:43:01.387: >> 1 capability<cr><lf>
22:43:01.387: << * CAPABILITY IMAP4rev1 STARTTLS X-MERCURY<cr><lf>
22:43:01.397: << 1 OK CAPABILITY complete.<cr><lf>
22:43:01.397: >> 2 STARTTLS<cr><lf>
22:43:01.397: << 2 OK Begin SSL/TLS negotiation now.<cr><lf>
22:43:01.427: [*] SSL/TLS session established: 3DES, CBC mode, keysize 192 
bits
22:43:01.437: >> 3 capability<cr><lf>
22:43:01.437: << * CAPABILITY IMAP4rev1 X-MERCURY<cr><lf>
22:43:01.437: << 3 OK CAPABILITY complete.<cr><lf>
22:43:01.447: >> 4 login "user" "password"<cr><lf>
22:43:01.497: << 4 OK LOGIN completed.<cr><lf>
-----------------

Comment 1

[Luigi D. Sandon]

My previous description may be not clear: in Mercury/32 I enabled the setting "Disable plain-text login for non TSL sessions", I did not disabled LOGIN completely. After STARTTLS completes, login is valid.

That's why the first CAPABILITY response contains LOGINDISABLED but the second doesn't. The RFC tells explicitly that after STARTTLS the server can advertise different capabilities.

Comment 2

[David :Bienvenu]

can you try a trunk TB build? I believe I checked in a fix for this on the trunk. Marking dup of bug 312009, which is fixed on the trunk.

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

Comment 3

[Luigi D. Sandon]

I can try a trunk build, as long as I have not to compile it myself. Where can I find it?

Comment 4

[David :Bienvenu]

latest trunk nightlies are here:

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

Comment 5

[Luigi D. Sandon]

Installed version 1.6a1 (20051123). LOGIN after STARTTLS now works, but it looks TB has problems when I click on some IMAP folders:

21:49:42.448: << 1 OK Begin SSL/TLS negotiation now.<cr><lf>
21:49:42.578: 22: Error -15 activating SSL session (locus 0, type 0, code 40, 'Received SSL alert message: Handshake failed')

21:49:40.025: << 1 OK Begin SSL/TLS negotiation now.<cr><lf>
21:49:40.275: 22: Error -22 activating SSL session (locus 0, type 0, code 51, 'Received TLS alert message: Decrypt error')

But probably that's another issue.

Comment 6

[David :Bienvenu]

that probably is an other issue. That might be related to some of the STARTTLS issues we've heard about in other bugs.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

When you receive an SSL/TLS alert message, it means that your peer (party 
on the other end of the connection) has experienced an error that will
prevent it from continuing to use SSL/TLS with you.  To find out more,
I suggest you look in the log file(s, if any) of your server.   

Comment 8

[Luigi D. Sandon]

I sent the logs to the mail server tech support already.