Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#654853: ejabberd: libpurple-based implementations cannot authorize with DIGEST-MD5

2 views
Skip to first unread message

Nicolas Évrard

unread,
Jun 13, 2012, 2:40:02 PM6/13/12
to
Package: ejabberd
Followup-For: Bug #654853

Dear Maintainer,

We installed the new version of ejabberd on our server but
unfortunately I still can not authenticate.

>From my musing with ejabber it seems that the problem is happening in
cyrsasl_digest.erl on

mech_step(#state{step = 3, nonce = Nonce} = State, ClientIn) ->
case parse(ClientIn) of
bad ->
{error, "bad-protocol"};
KeyVals ->
DigestURI = xml:get_attr_s("digest-uri", KeyVals),
UserName = xml:get_attr_s("username", KeyVals),
case is_digesturi_valid(DigestURI, State#state.host, State#state.hostfqdn) of
false ->
?DEBUG("User login not authorized because digest-uri "
"seems invalid: ~p (checking for Host ~p, FQDN ~p)", [DigestURI,
State#state.host, State#state.hostfqdn]),
{error, "not-authorized", UserName};
true ->
AuthzId = xml:get_attr_s("authzid", KeyVals),
case (State#state.get_password)(UserName) of
{false, _} ->
?DEBUG("~p 1", [UserName]),
{error, "not-authorized", UserName};
{Passwd, AuthModule} ->
case (State#state.check_password)(UserName, "",
xml:get_attr_s("response", KeyVals),
fun(PW) -> response(KeyVals, UserName, PW, Nonce, AuthzId,
"AUTHENTICATE") end) of
{true, _} ->
RspAuth = response(KeyVals,
UserName, Passwd,
Nonce, AuthzId, ""),
{continue,
"rspauth=" ++ RspAuth,
State#state{step = 5,
auth_module = AuthModule,
username = UserName,
authzid = AuthzId}};
false ->
?DEBUG("~p 2", [UserName]),
{error, "not-authorized", UserName};
{false, _} ->
?DEBUG("~p 3", [UserName]),
{error, "not-authorized", UserName}
end
end
end
end;

In the "2" stage of the debug but I don't know what it means (I
suppose there is a check_password method in State that fails)

-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Konstantin Khomoutov

unread,
Jun 13, 2012, 5:20:02 PM6/13/12
to
On Wed, Jun 13, 2012 at 08:22:47PM +0200, Nicolas Évrard wrote:

> Package: ejabberd
> Followup-For: Bug #654853
>
> Dear Maintainer,
>
> We installed the new version of ejabberd on our server but
> unfortunately I still can not authenticate.
[...]

Can you please be more precise about "the new version of ejabberd"?

This bug has been fixed upstream in 2.1.11 which is currently
pending an upload (Gerfried told me the upload has chances to happen
this weekend) hence if you installed a new version you either built it
from the upstream tarball or installed in using their binary installer
or installed a not-so-recent version. In the former two cases please
comment in the upstream BTS, in the latter please wait for the
prospective upload.

The relevant commit in our debianization repo is
http://git.deb.at/w/pkg/ejabberd.git/commit/0279b4106c2e4af880a001ab45c23c55da5df012

Konstantin Khomoutov

unread,
Jun 14, 2012, 11:20:02 AM6/14/12
to
On Thu, 14 Jun 2012 11:18:01 +0200
Nicolas Évrard <ni...@no-log.org> wrote:

> * Konstantin Khomoutov [2012-06-13 22:55 +0200]:
> >On Wed, Jun 13, 2012 at 08:22:47PM +0200, Nicolas Évrard wrote:
> >
> >> Package: ejabberd
> >> Followup-For: Bug #654853
> >>
> >> Dear Maintainer,
> >>
> >> We installed the new version of ejabberd on our server but
> >> unfortunately I still can not authenticate.
> >[...]
> >
> >Can you please be more precise about "the new version of ejabberd"?
> >
> >This bug has been fixed upstream in 2.1.11 which is currently
> >pending an upload (Gerfried told me the upload has chances to happen
> >this weekend) hence if you installed a new version you either built
> >it from the upstream tarball or installed in using their binary
> >installer or installed a not-so-recent version. In the former two
> >cases please comment in the upstream BTS, in the latter please wait
> >for the prospective upload.
>
> I am using minbiff to connect to a ejabberd hosted on a gentoo server.
> The running version there is 2.1.11 and unless you patch the said file
> I am afraid that the bug is also present in debian.

Well, I've just installed Pidgin on my desktop Windows machine
and connected to an ejabberd 2.11.1-1 instance installed into a Sid
sandbox. The Pidgin version is

Pidgin 2.10.4 (libpurple 2.10.4)
03f3e779309e683d092706d76a5253c6794d3a66

Here are excerpts from what I've got in Pidgin's debug log:

(18:53:44) proxy: Connected to jukebox.domain007.com:5222.
(18:53:44) jabber: Sending (kostix@localhost): <?xml version='1.0' ?>
(18:53:44) jabber: Sending (kostix@localhost): <stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(18:53:44) jabber: Recv (611): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='3743159023' from='localhost' version='1.0' xml:lang='en'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.process-one.net/en/ejabberd/' ver='TQ2JFyRoSa70h2G1bpgjzuXb2sU='/><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
(18:53:44) jabber: Sending (kostix@localhost): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(18:53:44) jabber: Recv (50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
[...]
(18:53:44) certificate: Successfully verified certificate for jukebox.domain007.com
(18:53:44) jabber: Sending (ssl) (kostix@localhost): <stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(18:53:44) jabber: Recv (ssl)(166): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='358372238' from='localhost' version='1.0' xml:lang='en'>
(18:53:44) jabber: Recv (ssl)(393): <stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.process-one.net/en/ejabberd/' ver='TQ2JFyRoSa70h2G1bpgjzuXb2sU='/><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
(18:53:44) sasl: Mechs found: SCRAM-SHA-1 DIGEST-MD5 PLAIN
(18:53:44) sasl: No worthy mechs found
[...]
(18:53:53) sasl: Mechs found: SCRAM-SHA-1 DIGEST-MD5 PLAIN
(18:53:53) sasl: DIGEST-MD5 client step 1
(18:53:53) jabber: Sending (ssl) (kostix@localhost): <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5' xmlns:ga='http://www.google.com/talk/protocol/auth' ga:client-uses-full-bind-result='true'>password removed</auth>
(18:53:53) jabber: Recv (ssl)(148): <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bm9uY2U9IjIzMTQ4NDk2OTEiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=</challenge>
(18:53:53) sasl: DIGEST-MD5 client step 2
(18:53:53) jabber: Sending (ssl) (kostix@localhost): <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcm5hbWU9Imtvc3RpeCIscmVhbG09Imp1a2Vib3guZG9tYWluMDA3LmNvbSIsbm9uY2U9IjIzMTQ4NDk2OTEiLGNub25jZT0iT1MwSFRXUm1RaVp3WFhwMlJSSTdIbTRhWTJ0L2YwNHlJaVpyQXpBTFZnYz0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvanVrZWJveC5kb21haW4wMDcuY29tIixyZXNwb25zZT1mZTIyZTg1YWZkMGQwMGYwZDZkODYyODdmYmZmNTQwNyxjaGFyc2V0PXV0Zi04</response>
(18:53:53) jabber: Recv (ssl)(120): <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cnNwYXV0aD1mZmE3YTgwYzA2YTZkZTUyYWVhNGY0ODUwYTgyNzYyZQ==</challenge>
(18:53:53) sasl: DIGEST-MD5 client step 3
(18:53:53) jabber: Sending (ssl) (kostix@localhost): <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(18:53:53) jabber: Recv (ssl)(51): <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(18:53:53) jabber: Sending (ssl) (kostix@localhost): <stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(18:53:53) jabber: Recv (ssl)(167): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='1917317317' from='localhost' version='1.0' xml:lang='en'>
(18:53:53) jabber: Recv (ssl)(334): <stream:features><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.process-one.net/en/ejabberd/' ver='TQ2JFyRoSa70h2G1bpgjzuXb2sU='/><register xmlns='http://jabber.org/features/iq-register'/></stream:features>

I have one "host" (XMPP domain) in my ejabberd configuration --
"localhost".
The real host name of the machine which runs the sandbox is
jukebox.domain007.com (don't ask why it is what it is), and I have
configured it in my Pidgin config as the server to connect to (so no
SRV lookups are performed).

As you can see, I have successfully authenticated as "kostix@localhost"
using DIGEST-MD5 after upgrading the session to use TLS.

So, to me the issue appears to be either fixed or non-existing.
Is there something in my setup (XMPP domain? server hostname?
client settings?) that prevents the issue being discussed form
exposing itself?

P.S.
Please don't cull the bug's e-mail address from the Cc list.

Nicolas Évrard

unread,
Jun 14, 2012, 11:20:03 AM6/14/12
to
* Konstantin Khomoutov [2012-06-13 22:55 +0200]:
>On Wed, Jun 13, 2012 at 08:22:47PM +0200, Nicolas Évrard wrote:
>
>> Package: ejabberd
>> Followup-For: Bug #654853
>>
>> Dear Maintainer,
>>
>> We installed the new version of ejabberd on our server but
>> unfortunately I still can not authenticate.
>[...]
>
>Can you please be more precise about "the new version of ejabberd"?
>
>This bug has been fixed upstream in 2.1.11 which is currently
>pending an upload (Gerfried told me the upload has chances to happen
>this weekend) hence if you installed a new version you either built it
>from the upstream tarball or installed in using their binary installer
>or installed a not-so-recent version. In the former two cases please
>comment in the upstream BTS, in the latter please wait for the
>prospective upload.

I am using minbiff to connect to a ejabberd hosted on a gentoo server.
The running version there is 2.1.11 and unless you patch the said file
I am afraid that the bug is also present in debian.

--
(°> Nicolas Évrard
( ) Liège

signature.asc

Konstantin Khomoutov

unread,
Jun 14, 2012, 11:40:01 AM6/14/12
to
On Thu, 14 Jun 2012 11:18:01 +0200
Nicolas Évrard <ni...@no-log.org> wrote:

[...]
> >> We installed the new version of ejabberd on our server but
> >> unfortunately I still can not authenticate.
> >[...]
> >
> >Can you please be more precise about "the new version of ejabberd"?
> >
> >This bug has been fixed upstream in 2.1.11 which is currently
> >pending an upload (Gerfried told me the upload has chances to happen
> >this weekend) hence if you installed a new version you either built
> >it from the upstream tarball or installed in using their binary
> >installer or installed a not-so-recent version. In the former two
> >cases please comment in the upstream BTS, in the latter please wait
> >for the prospective upload.
>
> I am using minbiff to connect to a ejabberd hosted on a gentoo server.
> The running version there is 2.1.11 and unless you patch the said file
> I am afraid that the bug is also present in debian.

I also see that in your initial mail you said your minbif is linked
against libpurple 2.10.1, and I have 2.10.4 here.
Do you have a chance of re-trying with something linked against 2.10.4
(which appears to be the most recent version)?

Nicolas Évrard

unread,
Jun 14, 2012, 12:40:02 PM6/14/12
to
* Konstantin Khomoutov [2012-06-14 17:12 +0200]:
>On Thu, 14 Jun 2012 11:18:01 +0200
>Nicolas Évrard <ni...@no-log.org> wrote:
>
>> * Konstantin Khomoutov [2012-06-13 22:55 +0200]:
>> >On Wed, Jun 13, 2012 at 08:22:47PM +0200, Nicolas Évrard wrote:
>> >
>> >> Package: ejabberd
>> >> Followup-For: Bug #654853
>> >>
>> >> Dear Maintainer,
>> >>
>> >> We installed the new version of ejabberd on our server but
>> >> unfortunately I still can not authenticate.
>> >[...]
>> >
>> >Can you please be more precise about "the new version of ejabberd"?
>> >
>> >This bug has been fixed upstream in 2.1.11 which is currently
>> >pending an upload (Gerfried told me the upload has chances to happen
>> >this weekend) hence if you installed a new version you either built
>> >it from the upstream tarball or installed in using their binary
>> >installer or installed a not-so-recent version. In the former two
>> >cases please comment in the upstream BTS, in the latter please wait
>> >for the prospective upload.
>>
>> I am using minbiff to connect to a ejabberd hosted on a gentoo server.
>> The running version there is 2.1.11 and unless you patch the said file
>> I am afraid that the bug is also present in debian.
>
>Well, I've just installed Pidgin on my desktop Windows machine
>and connected to an ejabberd 2.11.1-1 instance installed into a Sid
>sandbox. The Pidgin version is
>
>Pidgin 2.10.4 (libpurple 2.10.4)
>03f3e779309e683d092706d76a5253c6794d3a66

I am also using this version:

balisto:~% pidgin --version
Pidgin 2.10.4 (libpurple 2.10.4)


> … snip …
>
>I have one "host" (XMPP domain) in my ejabberd configuration --
>"localhost".
>The real host name of the machine which runs the sandbox is
>jukebox.domain007.com (don't ask why it is what it is), and I have
>configured it in my Pidgin config as the server to connect to (so no
>SRV lookups are performed).
>
>As you can see, I have successfully authenticated as "kostix@localhost"
>using DIGEST-MD5 after upgrading the session to use TLS.
>
>So, to me the issue appears to be either fixed or non-existing.
>Is there something in my setup (XMPP domain? server hostname?
>client settings?) that prevents the issue being discussed form
>exposing itself?

From my debugging session in the ejabber the URI problem is solved.
Maybe I should make another bug (but before I'll wait for the ejabberd
upload to get the fixed version).
signature.asc
0 new messages