635628 - [autoconfig] Reinstate password fallback for Kerberos/GSSAPI failure on secure connections during account verification

Status: NEW

(Thunderbird :: Account Manager, defect)

Description

[rsx11m]

Kerberos / GSSAPI authentication may fail due to various reasons, it may be advertised but not be configured on the server's side, or the user doesn't have it set up correctly. This was initially fixed in bug 491202 for the old account wizard, but apparently the redesign to provide more detailed menu options in bug 525238 voided that fix. Both the current TB 3.1.x account wizard and the redesign per bug 549045 enforce Kerberos / GSSAPI as security mechanism even
if normal password would be available as a fallback.

The suggestion is to fall back to password-based authentication if Kerberos fails in the "Create Account" step for account verification. The related discussion in prior bugs is reiterated below for reference.

(Quoting bug 549045 comment #165 of 2011-02-20)
> 
> While the server name, ports, and connection encryption where guessed correctly
> in the 2nd scenario, I ran into a regression of bug 491202 (no fallback to
> password authentication when Kerberos/GSSAPI is advertised but not configured).
> After going to "Manual Config" and changing to "Normal Password", retesting
> and account creation was successful (switching to "Autodetect" just gave me
> Kerberos again, so that didn't help).
> 
> On a side note, the initial error message of "user name or password are wrong"
> didn't reflect that the Kerberos-ticket failed and may be misleading for the
> unsuspecting user. This actually seems to be a regression from bug 525238
> rather as I see the same behavior in the 3.1.8 release build, so this would
> probably be a candidate for a separate bug either way.

(Quoting bug 491202 comment #54 of 2009-11-21)
> First, note all this does not affect configs fetched from our database or the
> ISP. Below is only about guessed configs.
> 
> I'm working on this code in bug 495412.
> 
> I notice that - during config guessing - we do not fall back to plaintext auth
> unless we have SSL/STARTTLS - during verification.
> <http://hg.mozilla.org/comm-central/annotate/54c135ebb58c/mailnews/base/prefs/content/accountcreation/verifyConfig.js#l227>
> However, we don't have any problem with using plaintext auth on insecure
> connections when the server never advertises any secure auth (like GSSAPI or
> MD5). That doesn't make sense.
> 
> In other words, a server that has no SSL and does not support encrypted
> passwords nor Kerberos will work, we'll set up the account (after a warning).
> A server that has no SSL and does not support encrypted passwords, but
> advertises "GSSAPI", but GSSAPI/Kerberos fails during verification (because
> it's not set up on client or server), we'll fail entirely and can't set up the
> account, and even claim the username/password is wrong.
> I think the second scenario is no less secure than the first. Therefore, I
> think we should allow that - if we warn(ed) the user.
> 
> Is that OK, if I change it like that?

I'm not sure why I didn't respond to the latter question, I either missed it or must have assumed that it was directed towards Blake.

Comment 1

[Jens Müller (:tessarakt)]

I think I saw this today, too, on an Exchange server.