possible XMPP SASL bug?

[Joe Hildebrand]

Two issues now:

- the password prompt doesn't say that the username/password was bad, so it
might be confusing. "How come it keeps popping up?!" (I've got some, um,
"business users" who need the password problem to show in the UI)

- If I put in the correct password, it's not saved, so disconnect/reconnect
fails.


On 5/3/10 8:39 PM, "Evan Schoenberg, M.D." <evan at adium.im> wrote:

> Joe, http://adiumx.cachefly.net/Adium_1.4b18.dmg should fully resolve this.
> 
> Guys, I'll put a changelog up tomorrow evening and push the appcast for it.
> If someone beats me to it, excellent.  Consider this "rc1 except for 7
> tickets".
> 
> Cheers,
> Evan
> 
> 
> On May 3, 2010, at 4:38 PM, Joe Hildebrand wrote:
> 
>> Attached.  Line to focus on:
>> 
>> 15:35:58: <ESPurpleJabberAccount:385a9c0 2>:testuser at webex.com: Disconnected
>> ("SASL authentication failed"): Automatically reconnecting in 5.000000
>> seconds (0 attempts performed)
>> 
>> 
>> 
>> On 5/3/10 3:03 PM, "Evan Schoenberg, M.D." <evan at adium.im> wrote:
>> 
>>> 
>>> On May 3, 2010, at 3:49 PM, Joe Hildebrand wrote:
>>> 
>>>> This *almost* works.  The error is now correct, but we shouldn't
>>>> auto-reconnect if the password was bad.
>>> 
>>> I agree; however, code is already in place which should be handling that.
>>> Please post debug logging of sending an incorrect password and not getting
>>> prompted to enter a correct one.
>>> 
>>> -Evan
>>> 
>>>> 
>>>> 
>>>> On 5/3/10 2:30 PM, "Evan Schoenberg, M.D." <evan at adium.im> wrote:
>>>> 
>>>>> 
>>>>> On May 3, 2010, at 11:42 AM, David Smith wrote:
>>>>> 
>>>>>> I'd be happy to check if I can still connect to iChat Server if someone
>>>>>> gives
>>>>>> me a patched Adium.
>>>>> 
>>>>> 
>>>>> I should have checked the code instead of the ticket; I left later-me some
>>>>> good details there.
>>>>> jabber_auth_start_cyrus() for us includes:
>>>>> {
>>>>> /* We have no mechs which can work.
>>>>> * Try falling back on the old jabber:iq:auth method. We get here if the
>>>>> server
>>>>> supports
>>>>> * one or more sasl mechs, we are compiled with cyrus-sasl support, but we
>>>>> support or can connect with none of
>>>>> * the offerred mechs. jabberd 2.0 w/ SASL and Apple's iChat Server 10.5
>>>>> both
>>>>> handle and expect
>>>>> * jabber:iq:auth in this situation.  iChat Server in particular offers
>>>>> SASL
>>>>> GSSAPI by default, which is often
>>>>> * not configured on the client side, and expects a fallback to
>>>>> jabber:iq:auth
>>>>> when it (predictably) fails.
>>>>> *
>>>>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure
>>>>> is
>>>>> wrong. However,
>>>>> * I believe this refers to actual authentication failure, not a simple
>>>>> lack
>>>>> of
>>>>> concordant mechanisms.
>>>>> * Doing otherwise means that simply compiling with SASL support renders
>>>>> the
>>>>> client unable to connect to servers
>>>>> * which would connect without issue otherwise. -evands
>>>>> */
>>>>> js->auth_mech = NULL;
>>>>> jabber_auth_start_old(js);
>>>>> return JABBER_SASL_STATE_CONTINUE;
>>>>> }
>>>>> 
>>>>> 
>>>>> However, elsewhere in auth_cyrus, jabber_cyrus_handle_failure() has what
>>>>> appears to be better logic:
>>>>> 
>>>>> if (tried_gssapi_first) {
>>>>> /* If we tried GSSAPI first, it failed, and it was our only shot, try
>>>>> jabber:iq:auth
>>>>> * for compatibility with iChat 10.5 Server.
>>>>> *
>>>>> * iChat Server 10.5  offers SASL GSSAPI by default, which is often
>>>>> * not configured on the client side, and expects a fallback to
>>>>> jabber:iq:auth
>>>>> when it (predictably) fails.
>>>>> *
>>>>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure
>>>>> is
>>>>> wrong. However,
>>>>> * I believe this refers to actual authentication failure, not a simple
>>>>> lack
>>>>> of
>>>>> concordant mechanisms.
>>>>> * Doing otherwise means that simply compiling with SASL support renders
>>>>> the
>>>>> client unable to connect to servers
>>>>> * which would connect without issue otherwise. -evands
>>>>> */
>>>>> sasl_dispose(&js->sasl);
>>>>> js->sasl = NULL;
>>>>> js->auth_mech = NULL;
>>>>> jabber_auth_start_old(js);
>>>>> return JABBER_SASL_STATE_CONTINUE;
>>>>> }
>>>>> 
>>>>> (comments expanded just-now by me).
>>>>> In im.pigin.adium.1-4's 2fcd834324b05d3becf6878db8ce1c474578e720 I have
>>>>> removed the former, aggressive behavior and left the latter.  I think this
>>>>> should solve the problem presented while maintaining the workaround for
>>>>> iChat
>>>>> Server 10.5's apparent wrongness.
>>>>> 
>>>>> 
>>>>> This is committed in adium-1.4's
>>>>> [6534647aece5289a0e5ac90c012bcbf75e3918f3].
>>>>> 
>>>>> A build for testing is uploaded at
>>>>> http://adiumx.cachefly.net/Adium_1.4b18-noJabberHack.dmg
>>>>> 
>>>>> The downgrade attack Joe mentions does still exist, but now if and only if
>>>>> ((GSSAPI is the only offered SASL mech) && (GSSAPI fails)).  Further
>>>>> improvement would be a prompt as described in that setting; patches
>>>>> welcome.
>>>>> 
>>>>> Look forward to any feedback.
>>>>> 
>>>>> -Evan
>>>> 
>>>> -- 
>>>> Joe Hildebrand
>>>> 
>>>> 
>>> 
>>> 
>> 
>> -- 
>> Joe Hildebrand
>> 
>> <recon.log>
> 

-- 
Joe Hildebrand