*What steps will reproduce the problem?*
1. start prosody, try to establish a connection from a smack client.
*2.*
*3.*
What is the expected output? expected connection established.
What do you see instead? failure,
but I can connect to tigase and gtalk using the same client.
What version of the product are you using?
deb http://packages.prosody.im/debian intrepid main
On what operating system? ubuntu
*Please provide any additional information below.*
using selfsignedcert, and set allowselfsignedcerts=true in smack (works for
tigase)
I am also able to connect to the prosody server with psi with the same
account details.
Nov 12 14:00:51 socket debug server.lua: accepted new client connection
from clientip.1.1:3051 to 5222
Nov 12 14:00:51 sessionmanager debug open sessions now: 3
Nov 12 14:00:51 c2s1141510 info Client connected
Nov 12 14:00:52 c2s1141510 debug Client sent opening <stream:stream>
to myserver.com
Nov 12 14:00:52 c2s1141510 debug Sent reply <stream:stream> to client
Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Nov 12 14:00:52 modulemanager debug Passing stanza to mod_tls
Nov 12 14:00:52 c2s1141510 info TLS negotiation started...
Nov 12 14:00:52 socket debug server.lua: error during ssl handshake:
wantread
Nov 12 14:00:52 socket debug server.lua: error during ssl handshake:
wantread
Nov 12 14:00:52 socket debug server.lua: error during ssl handshake:
wantread
Nov 12 14:00:52 socket debug server.lua: ssl handshake done
Nov 12 14:00:52 c2s1141510 debug Client sent opening <stream:stream>
to myserver.com
Nov 12 14:00:52 c2s1141510 debug Sent reply <stream:stream> to client
Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <auth
mechanism='DIGEST-MD5' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Nov 12 14:00:52 modulemanager debug Passing stanza to mod_saslauth
Nov 12 14:00:52 myserver.com:saslauth debug
nonce="5441634d-a25d-458b-911c-a9680d5cf2ec",qop="auth",charset=utf-8,algorithm=md5-sess,realm="myserver.com"
Nov 12 14:00:52 myserver.com:saslauth debug sasl reply: <challenge
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bm9uY2U9IjU0NDE2MzRkLWEyNWQtNDU4Yi05MTFjLWE5NjgwZDVjZjJlYyIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2VzcyxyZWFsbT0iZXBzby5mdHJkLmpwIg==</challenge>
Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <response
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
Nov 12 14:00:52 modulemanager debug Passing stanza to mod_saslauth
Nov 12 14:00:52 myserver.com:saslauth debug
charset=utf-8,username="atlas.10btn",realm="myserver.com",nonce="5441634d-a25d-458b-911c-a9680d5cf2ec",nc=00000001,cnonce="Q+V7njs7etcJla6X97E+ePnasURR//7ZYWeOF8zQ",digest-uri="xmpp/myserver.com",maxbuf=65536,response=de392502a4adf8d8dbc27a7a4585d05d,qop=auth,authzid="atlas.10btn"
Nov 12 14:00:52 myserver.com:saslauth debug sasl reply: <failure
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text>The
response provided by the client doesn't match the one we
calculated.</text></failure>
Nov 12 14:00:53 socket debug server.lua: client clientip.1.1:3051 error:
closed
Nov 12 14:00:53 c2s1141510 info Client disconnected: closed
Nov 12 14:00:53 c2s1141510 info Destroying session for (unknown)
((unknown)@myserver.com)
Nov 12 14:00:53 socket debug server.lua: closed client handler and
removed socket from list
MattJ
on
Yet another DIGEST-MD5 issue - Tobias can you look into it? If it's a Smack bug then
report a bug there please.
Changes
tags Status-Accepted
owner tmarkmann
Waqas
on
From a quick read of sasl.lua, the problem is the authzid the client provides. Smack
is in violation of RFC 3920 section 6.1 point 7.
For compatibility, we accept authzids of the form "user@host", however smack provides
just "user". This can be fixed quite simply.
Additionally, sasl.lua isn't returning the proper error: invalid-authzid.
Changes
tags Milestone-0.6
jeacott1
on
I think smack provides whatever is put in the username field (different servers seem
to vary what they require on this point). I tried using both user@host, and just the
user part, made no difference, but its possible smack may still be sending just the
user part.
*What steps will reproduce the problem?* 1. start prosody, try to establish a connection from a smack client. *2.* *3.* What is the expected output? expected connection established. What do you see instead? failure, but I can connect to tigase and gtalk using the same client. What version of the product are you using? deb http://packages.prosody.im/debian intrepid main On what operating system? ubuntu *Please provide any additional information below.* using selfsignedcert, and set allowselfsignedcerts=true in smack (works for tigase) I am also able to connect to the prosody server with psi with the same account details. Nov 12 14:00:51 socket debug server.lua: accepted new client connection from clientip.1.1:3051 to 5222 Nov 12 14:00:51 sessionmanager debug open sessions now: 3 Nov 12 14:00:51 c2s1141510 info Client connected Nov 12 14:00:52 c2s1141510 debug Client sent opening <stream:stream> to myserver.com Nov 12 14:00:52 c2s1141510 debug Sent reply <stream:stream> to client Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> Nov 12 14:00:52 modulemanager debug Passing stanza to mod_tls Nov 12 14:00:52 c2s1141510 info TLS negotiation started... Nov 12 14:00:52 socket debug server.lua: error during ssl handshake: wantread Nov 12 14:00:52 socket debug server.lua: error during ssl handshake: wantread Nov 12 14:00:52 socket debug server.lua: error during ssl handshake: wantread Nov 12 14:00:52 socket debug server.lua: ssl handshake done Nov 12 14:00:52 c2s1141510 debug Client sent opening <stream:stream> to myserver.com Nov 12 14:00:52 c2s1141510 debug Sent reply <stream:stream> to client Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <auth mechanism='DIGEST-MD5' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Nov 12 14:00:52 modulemanager debug Passing stanza to mod_saslauth Nov 12 14:00:52 myserver.com:saslauth debug nonce="5441634d-a25d-458b-911c-a9680d5cf2ec",qop="auth",charset=utf-8,algorithm=md5-sess,realm="myserver.com" Nov 12 14:00:52 myserver.com:saslauth debug sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bm9uY2U9IjU0NDE2MzRkLWEyNWQtNDU4Yi05MTFjLWE5NjgwZDVjZjJlYyIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2VzcyxyZWFsbT0iZXBzby5mdHJkLmpwIg==</challenge> Nov 12 14:00:52 c2s1141510 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Nov 12 14:00:52 modulemanager debug Passing stanza to mod_saslauth Nov 12 14:00:52 myserver.com:saslauth debug charset=utf-8,username="atlas.10btn",realm="myserver.com",nonce="5441634d-a25d-458b-911c-a9680d5cf2ec",nc=00000001,cnonce="Q+V7njs7etcJla6X97E+ePnasURR//7ZYWeOF8zQ",digest-uri="xmpp/myserver.com",maxbuf=65536,response=de392502a4adf8d8dbc27a7a4585d05d,qop=auth,authzid="atlas.10btn" Nov 12 14:00:52 myserver.com:saslauth debug sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text>The response provided by the client doesn't match the one we calculated.</text></failure> Nov 12 14:00:53 socket debug server.lua: client clientip.1.1:3051 error: closed Nov 12 14:00:53 c2s1141510 info Client disconnected: closed Nov 12 14:00:53 c2s1141510 info Destroying session for (unknown) ((unknown)@myserver.com) Nov 12 14:00:53 socket debug server.lua: closed client handler and removed socket from list
Yet another DIGEST-MD5 issue - Tobias can you look into it? If it's a Smack bug then report a bug there please.
ChangesFrom a quick read of sasl.lua, the problem is the authzid the client provides. Smack is in violation of RFC 3920 section 6.1 point 7. For compatibility, we accept authzids of the form "user@host", however smack provides just "user". This can be fixed quite simply. Additionally, sasl.lua isn't returning the proper error: invalid-authzid.
ChangesI think smack provides whatever is put in the username field (different servers seem to vary what they require on this point). I tried using both user@host, and just the user part, made no difference, but its possible smack may still be sending just the user part.
Added a workaround for Smack's behavior: http://prosody.im/source/hg/index.cgi/rev/5334723fa24d
Changes