MSN AUTH authentication stops working after upgrade to 1.5b2 from 1.0.7 due MSN using deprecated LM/NTLM mechanism

NEW
Unassigned

Status

--
minor
13 years ago
10 years ago

People

(Reporter: alyandon, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: workaround comment 13)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

I'm no longer able to retrieve email from my @msn.com account after upgrading
from 1.0.7 to 1.5b2.  Thunderbird reports that the authentication failed.  

Sniffing the traffic with Ethereal yielded what looks like a normal NTLM
authentication sequence which ultimately is rejected with an authorization
failed response from the MSN POP3 server.

Reproducible: Always

Steps to Reproduce:
1.  Enter @msn.com account as POP3 account.
2.  Go into preferences and enable "use secure authentication"
3.  Try to fetch email

Actual Results:  
Thunderbird prompts for password to msn.com account.  After entering the correct
password TB responds with a message that authorization failed.

Expected Results:  
Authentication should have worked.

I've verified that I'm able to access this @msn.com account through Outlook
Express and Mailwasher to try and rule out a transient issue with the account
itself.

Comment 1

13 years ago
The same thing happened to me when I did an in place upgrade.

I did a network sniff of what is going on and the only difference that I can between the two clients is that 1.0.7 sends:

AUTH
CAPA
AUTH MSN

While 1.5 send:
CAPA
AUTH MSN

Both fail on the CAPA command with a "-ERR authorization failed". But it seems that you need an initial OK response that gets sent back by the initial AUTH before the AUTH MSN (which sends back a "Continuation packet")

Comment 2

13 years ago
I too have the exact same problem as described. 

Comment 3

12 years ago
I have the same problem.  Thunderbird 1.0.7 worked, 1.5.0.5 does not.
(Reporter)

Comment 4

12 years ago
A workaround at this point in time is to install the Webmail + Hotmail extensions to access your @msn.com accounts.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

12 years ago
This issue still exists in the 10/02/06 build.  
Terry, Reporter - would you be able to attach some pop3 protocol logs so the devs can try and see where/why this is failing?

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop
(Reporter)

Comment 7

12 years ago
I've long since disposed of my dialup @msn.com account.  However, I'm still able to access it through the Hotmail/Webdav extension so it looks like MSN never deprovisioned the account.  I went ahead and captured my attempt to access the account (one time via the troubleshooting log and one time via packet capture) via pop3 and have emailed it to you.

There is, of course, no guarantee that what you see now isn't an authentic response from their pop3 as opposed to what I first reported.
Created attachment 241142 [details]
protocol log from reporter

Comment 9

12 years ago
Created attachment 241165 [details]
SMTP Debug ouput for both successful and failed test cases. 

I had problems w/ latest installer so I reverted to latest public version (1.5.0.7) for the fail test case.  V1.0.6 works for me so I used it as the success test case.

Comment 10

12 years ago
Christian, any chance you might have a few cycles to investigate why msn auth stopped working in 1.5 and 2.0? comment 1 had some interesting observations. 

Comment 11

12 years ago
Without having tested it (where to get a @msn.com account with POP access from?), I guess the change from bug 250691 has caused the problem. That switched off sending of LM hash.

Just try switching (resp. adding) the boolean pref network.ntlm.send-lm-response to true and try to authenticate with the MSN server again. If that doesn't help I'll really need a test account.

Comment 12

12 years ago
Wow, thx, Christian

Comment 13

12 years ago
Terry and others who are having this problem. Can you please download a thunderbird 2 build from:

Start it up. Go to Tools / Options / Advanced / Config Editor.

In the filter text box, type: network.ntlm.send-lm-response

Change the value to true.

Restart Thunderbird and tell us if you still have this problem with MSN AUTH. Thank you!

Comment 14

12 years ago
This change worked like a charm for me.

Comment 15

12 years ago
> This change worked like a charm for me.

So you were able to retrieve your mail again? Glad that works.

Although that means that MSN indeed uses the oldest and most insecure mechanism of the LM/NTLM family (whose use is deprecated and discouraged for any desktop and enterprise user) for its service. That's great. :-((

Comment 16

12 years ago
thx for figuring this out, Christian! Just so I understand, we basically have to relnote this, right? We can't change the pref for Thunderbird, because we'll break other servers that do NTLM authentication? Or we could check for an msn account and toggle the pref while authenticating to MSN, but that's probably fraught with peril if we get simultaneous connections going on...

Comment 17

12 years ago
We could change the default of the pref to true. If I'm not totally wrong, enabling LM response doesn't break NTLM or NTLM2 (since they're sent in parallel). Three issues:
1. LM is less secure than NTLM. Sending it out really should only be enabled if there's no other way. Sending LM to servers which don't rely on it, would weaken the whole thing.
2. It prevents us from using LMv2 and NTLMv2 - but since those aren't implemented in our codebase yet, that doesn't matter for now.
3. SM would behave different (also enabling the pref there (resp. FF) would also affect usage of LM/NTLM in HTTP).

Yes, a hint for MSN users should go to the relnotes in any case.
I think it might be enough that we know this is the fix, especially if it's not very secure.  MSN users will appreciate the opportunity to know about it and complain.

Comment 19

12 years ago
This worked for me as well.  Thank you!
relnote perhaps was not a serious interest, but FWIW  I did not find one for 2.0.  OTOH, I didn't find any more obvious bugs filed about MSN, authentication or NTLM.
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Summary: MSN AUTH authetication stops working after upgrade to 1.5b2 from 1.0.7 → MSN AUTH authentication stops working after upgrade to 1.5b2 from 1.0.7 due MSN using deprecated LM/NTLM mechanism
Whiteboard: workaround comment 13
Version: unspecified → 1.5

Comment 21

11 years ago
This didn't work for Thunderbird 2.0. Do you have any more suggestions?
Assignee: mscott → nobody
(Reporter)

Comment 22

10 years ago
I could have sworn Microsoft migrated all MSN email accounts to live.com and no longer use SPA.  Anyway, try selecting SSL and unchecking the "Use secure authentication" option as a workaround.

Comment 23

10 years ago
In the newest Thunderbird and Firefox the pref files don't contain a 'network.ntlm.send-lm-response' line, so I couldn't try that patch.  -- Probably just as well.   
 Comment 22 solved my problem.  Does this setting provide an unacceptable security problem?

Comment 24

10 years ago
I have been successfully using TB version "2.0.0.17 (20080914)" on my Windows XP computers as well as on my wife's Mac computer with email on QWEST DSL with the MSN servers (our emails there are _@q.com).  To operate successfully, we added the hotmail webmail extension for q.com, and used these settings:

INCOMING SERVER: pop3.live.com
USER NAME:  (our q.com emails)
SECURE SSL CONNECTION
NO SECURE AUTHENITCATION
PORT 995

OUTGOING SERVER: LOCALHOST
USE SECURE AUTHENTICATION (with full email address)
NO SECURE CONNECTION
PORT 25

Today suddenly, I could no longer send any emails from any of my computers.  I tried changing the settings according to the instructions on this page, but that did not help:

http://kb.mozillazine.org/Creating_accounts_in_Thunderbird_for_popular_email_providers

I tried changing the setting in TB config editor as suggested:

"network.ntlm.send-lm-response must be set to true"

but that did not not help.  I still get TB "connect error 10060" messages saying I am not able to connect to SMTP server when I try to send any messages.  I can receive my email fine - I cannot send anything. I had this problem a year ago when I signed on with Qwest DSL, but the above procedure and settings worked fine for me until today.

I have tried using the outgoing server settings for MSN PREMIUM but they do not seem to work either.  I called QWEST DSL TECH SUPPORT and they could only suggest the MSN PREMIUM settings, and were unable to explain what had changed with the Microsoft Live servers that suddenly made my email sending stop working.  QWEST DSL TECH SUPPORT had me set up OUTLOOK EMAIL on my laptop and try that, but it also would not send.  The only thing that still worked was my email through the MSN LIVE HOTMAIL webmail IE client. 

PLEASE provide some kind of tip for me as to how I can get my TB working again!  I have no interest in resorting to using IE for my Qwest DSL mail application!  I am sure I am not the only one with this problem.  I appreciate any guidance!  Many thanks!  Please email me directly with any suggestions, but don't be surprised if you don't receive any response from me :-(
Lance, this is not a support forum. 
Please try e.g. http://forums.mozillazine.org/viewforum.php?f=39

Comment 26

10 years ago
We just moved our (internal, test) Windows exchange service to Windows 7 and now have the same problem with Thunderbird 2.0 (Windows & Linux). Symptoms:
- SPA/POP3 works, SPA/SMTP fails.
- If sender exchange account is "admin" SMTP port is 25 and SPA is not used (SMTP works). If sender exchange account is "user" then SMTP port becomes 587 and password is rejected.
- Outlook express produces the exact same result until: send and receive (POP3 & SMTP) are "tied together" for "logon" and SPA is enabled.
- there is web information dating back to 2004, where send and receive logons are bound together with "receive before send" options. There is also some ancient stuff (2006) about an "offline" extension that binds the SMTP logon to the POP3 logon.
You need to log in before you can comment on or make changes to this bug.