go-xmpp
go-xmpp copied to clipboard
auth failure: SASL negotiation is not allowed in this state
I am using "github.com/xmppo/go-xmpp" package then error I face is auth failure: SASL negotiation is not allowed in this state.
But While I am using "github.com/mattn/go-xmpp" is working . Please help me out why this happening.
Which version of go-xmpp do you use? What's the xmpp server in use? What version of the xmpp server? Can you show debug logs?
Am 30. April 2024 14:01:50 UTC schrieb anoop012345 @.***>:
I am using "github.com/xmppo/go-xmpp" package then error I face is auth failure: SASL negotiation is not allowed in this state.
But While I am using "github.com/mattn/go-xmpp" is working . Please help me out why this happening.
Thanks for the response . I am using ejabberd 23.1.0 and my go-xmpp vrsion is v0.2.0.
<?xml version='1.0'?><stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<?xml version='1.0'?><stream:stream id='18386229244849438105' version='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' xmlns='jabber:client'>
<stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>SCRAM-SHA-512-PLUS</mechanism><mechanism>SCRAM-SHA-512</mechanism><mechanism>SCRAM-SHA-256-PLUS</mechanism><mechanism>SCRAM-SHA-256</mechanism><mechanism>SCRAM-SHA-1-PLUS</mechanism><mechanism>SCRAM-SHA-1</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-512-PLUS'>cD10bHMtZXhwb3J0ZXIsLG49YWRtaW4scj1jMjk0NGRhMjk2N2RlYmJj</auth>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text xml:lang='en'>Invalid channel binding</text></failure>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xLRXIwWTFwSDAxeUQyNk9JUTByMnRZOXNCVVVsUk0wZ2VuLzJXL1hVZ2dtLHI9LHA9ODgzdTlNbFVhMDRFUWpxdTZkOEdTTjJSZmR6UXpTaWs0UzFEWEk2cXl1YVlUbE9SdWV4NXZHWE5vVEU1Szc0WXN1SzhVVUY0WjhjMnNMMWdqd3M2aEE9PQ==</response>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/><text xml:lang='en'>SASL negotiation is not allowed in this state</text></failure>
err: auth failure: SASL negotiation is not allowed in this state
Invalid channel binding
So it's an issue with channel binding. That could mean:
- There is an mitm attack between you and your server
- There is an bug in go-xmpps implementation
- There is an bug in ejabberds implementation
As there is a known issue in ejabberd for channel binding in ejabberd < 24.02 I assume the latter. Earlier version use tls-unique with TLSv1.3 although tls-exporter must be used. If the server is not yours and can't be upgraded to ejabberd 24.02 I suggest you to set Mechanism in Options temporarily to a mechanism without channel binding (e.g. SCRAM-SHA-512) until the server is upgraded to a version >= 24.02.
Did it help?
@anoop012345 Could you please give some feedback? Would be important to know whether it was a server issue or an issue with this lib.
@mdosch I have fixed this issue by passing the mechanism SCRAM-SHA-512 for xmpp.Options while creating the client. So this lib issue.
@mdosch I have fixed this issue by passing the mechanism SCRAM-SHA-512 for xmpp.Options while creating the client. So this lib issue.
So it does not happen anymore when you don't use a channel binding mechanism? Than it is very likely an ejabberd version <24.02 where channel binding has a bug when using TLSv1.3.
I don't understand what you mean by "So this lib issue."
He used your advice and it indeed helps. Since it is not lib-side bug, no changes in lib required. But maybe it is a good sign to start faq.md with common issues and confusions that can be resolved by proper usage of client options and such things?
Thanks for clarifying. For the faq recommendation: That's a good idea but I am currently pretty busy and it is not very high on my priorities list. But if you'd like to contribute one I'd be happy.
Indeed. Faq on this topic is pretty boring thing :) and that is one of the reasons why priority is low (same thing in many other projects). And the time is pretty much precious resource to waste it.