Just released Pidgin 2.4.0 -> OpenFire 3.4.5 -> "Not Authorized" on SSL login

Openfire Openfire Support
1

Hi,

Just a head-up for Pidgin users. The just released 2.4.0 is producing “Not Authorized” messages for anyone trying to log into our server.

Our Openfire 3.4.5 server has JIDs like

joe@centrex.com

bob@centrex.com and so forth.

The actual server’s FQDN however is jabber.centrex.org. Pidgin usually detects the SRV records for centrex.com and finds out that XMPP is at jabber.centrex.com.

Here’s where the problem seems to lie. Since Pidgin 2.4.0, it seems to do the SRV lookup and try to log users in as joe@jabber.centrex.com

The Openfire debug log shows:

2008.03.02 22:15:47 NIOConnection: startTLS: using c2s

2008.03.02 22:15:53 SASLAuthentication: SaslException

javax.security.sasl.SaslException: DIGEST-MD5: digest response format violation. Mismatched URI: xmpp/jabber.centrex.com; expecting: xmpp/centrex.com

The Pidgin debug log shows:

(00:21:28) account: Connecting to account joe@centrex.com/Home

(00:21:28) connection: Connecting. gc = 01A674F8

(00:21:28) dnssrv: querying SRV record for xmpp-client.tcp.centrex.com

(00:21:28) dnssrv: found 1 SRV entries

(00:21:28) dnsquery: Performing DNS lookup for jabber.centrex.com

(00:21:29) dnsquery: IP resolved for jabber.centrex.com

(00:21:29) proxy: Attempting connection to 21.32.57.77

(00:21:29) proxy: Connecting to jabber.centrex.com:5222 with no proxy

(00:21:29) proxy: Connection in progress

(00:21:30) proxy: Connected to jabber.centrex.com:5222.

(00:21:30) jabber: Sending:

(00:21:39) account: Disconnecting account 00C85138

(00:21:39) connection: Disconnecting connection 01A674F8

(00:21:39) connection: Destroying connection 01A674F8

2

Hey centrex,

AFAIK, there is no relation between DNS returned value and the XMPP domain used by the server and SASL authentication. Based on the following XML:

(00:21:31) jabber: Recv (188): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream=“http://etherx.jabber.org/streams” xmlns=“jabber:client” from=“centrex.com”

I see that the XMPP domain of your server is centrex.com. Therefore, the JID passed in the SASL mechanism should use the centrex.com domain and not the actual hostname where the server is running. You may want to contact the Pidgin devs to fix this problem. Clients should be using the XMPP domain returned in the stream header by the server.

Thanks,

– Gato

3

Correct, Pidgin 2.4.0 seems to do the SRV lookup, then try to login as user@ rather than the JID one has specified.

I logged it there as bug #5008. I posted it here purely for informational purposes.

4

Update: Turns out it’s not a Pidgin bug as such.

Pidgin developers got back to me and told me that this is related to http://www.igniterealtime.org/issues/browse/JM-952

I had to create an entry for xmpp.fqdn in the Openfire properties and the issue was resolved.

5

Hey centrex,

Even thought you may get around this problem using that property I’m not sure that is the correct solution. I have to say that I’m not an expert in SASL but I don’t think that the returned DNS value has anything to do with SASL. AFAIK, the DNS value may or may not be a FQDN (e.g. it might be just an IP address). IMO, clients should use the returned XMPP domain in the stream header as the XMPP server domain and not use the returned DNS value.

Thanks,

– Gato

6

Thanks Gato,

Yes, I agree, other clients like Psi and Spark did not need me to set xmpp.fqdn, and they could connect via SSL just fine. Also Pidgin 2.2.0 - 2.3.1 could connect just fine. Setting xmpp.fqdn seems to be more of a work-around than a fix, but I am happy that people from both the Pidgin and Openfire community replied and led me to the workaround in such a short time

I did make a bug report in the Pidgin bug tracker, but they blame Openfire, so I am not sure how I can push for more answers. I am just an admin, not a developer so it’s hard for me to articulate the issue in a way that gets their interest.

http://developer.pidgin.im/ticket/5008

7

Hi Gato,

I’m the person accused of “blaming” openfire - that isn’t exactly what I was trying to do.

First of all, we do only use XMPP JID domain in the stream header, it is only the digest-uri of SASL DIGEST-MD5 step 2 that uses the resolved FQDN of the server. Here is a bit of background at how I came to this, and my suggestion to set xmpp.fqdn:

At least for GSSAPI authentication using SASL it is essential to use the resolved FQDN of the XMPP server for authentication to succeed. Typically this is what is resolved using DNS SRV records, and not a IP address. For Openfire to work with this configuration, xmpp.fqdn must be set to match - I believe I got this originally from an Openfire provided howto for SSO.

Now with xmpp.fqdn configured for GSSAPI authentication to work, DIGEST-MD5 authentication with the Openfire server using Cyrus SASL on the Pidgin side requires the digest-uri in the response to be in the form xmpp/FQDN otherwise the server rejects it. If this is incorrect, and DIGEST-MD5 auth should in fact be using a digest-uri of xmpp/JIDdomain then I can accept that (given a little proof), but Openfire should not be expecting a digest-uri of xmpp/FQDN when xmpp.fqdn is set if both GSSAPI and DIGEST-MD5 are to work at the same time.

I’m also certainly no expert in these things, and am willing to listen to other explanations of what the correct configuration should be.

Regards,

Stu.

8

FWIW: Although I don’t have a lot of hard evidence, the xmpp.fqdn fix might cause problems with versions of pidgin prior to 2.4.0.

I did the work around and a friend, who was using pidgin 2.3.x, was unable to login to my openfire server.

9

If you are not using DNS SRV records to resolve to the FQDN of your server then yes, this might be a problem for earlier versions of Pidgin. Pidgin 2.4.0 fixes this by making use of the connect server to specify the FQDN used for SASL authentication when DNS SRV resolution fails.

If you wish to continue supporting older versions of Pidgin, you can do so by setting up DNS SRV records for your XMPP JID domain.

10

Well, maybe not … another friend was able to connect with Pidgin 2.2.1 with the xmpp.fqdn workaround applied.

11

nosnilmot wrote:

If you are not using DNS SRV records to resolve to the FQDN of your server then yes, this might be a problem for earlier versions of Pidgin. Pidgin 2.4.0 fixes this by making use of the connect server to specify the FQDN used for SASL authentication when DNS SRV resolution fails.

If you wish to continue supporting older versions of Pidgin, you can do so by setting up DNS SRV records for your XMPP JID domain.

Well, I am using SRV records … but I’m unsure if I completely understand what you are referring to.

My SRV records look something like this:

$ host -tsrv xmpp-client.tcp.example.com

xmpp-client.tcp.example.com has SRV record 5 0 5222 chat.example.com

david

12

OK, so I suspect your friend who failed to connect with Pidgin 2.3.x was specifying chat.example.com as the connect server in the Advanced options of his XMPP account - this bypasses SRV lookups, and in Pidgin < 2.4.0 results in (imho, incorrectly) the JID domain being used by SASL as the FQDN to use in the digest-uri.

I feel this is getting slightly off topic for Openfire’s forums, feel free to stop by devel@conference.pidgin.im (on XMPP) if you wish to discuss any of the Pidgin-specific aspects of this.

13

Sorry to dig this back up on the Ignite forums, but I can’t get into the Pidgin developer site to raise this again (Trac error boils down to: “TimeoutError: Unable to get database connection within 20 seconds”)…

We have our SRV records set up correctly:

$ host -tsrv xmpp-client.tcp.ggpsystems.co.uk

xmpp-client.tcp.ggpsystems.co.uk has SRV record 0 0 5222 svn.ggpsystems.co.uk.

For half our office (Psi 0.11) they get “Not authorized” if I add the xmpp.fqdn fix so the other half of the office (starting to use Pidgin 2.4.0) can work, and none of us are using manually specified server addresses…

Clearly, there’s something not right somewhere between server and client when it works for half of them with server configuration A, and the situation is reversed if we go over to server configuration B.

14

murray_ggp,

I observed the same thing.

xmpp.fqdn not set: All Psi and 2.2.x - 2.3.x Pidgin clients can connect fine, but Pidgin 2.4.0 clients are told “Not authorized”.

xmpp.fqdn set: All Pidgin clients can connect just fine, but psi clients can no longer connect. We’re a 100% Pidgin shop, so for me it was an easy call to set xmpp.fqdn.

Note that our clients all force secure connections, I suspect if you let them connect plain text, there wouldn’t be an issue.

15

I got the same problem with OpenFire 3.5.0 and pidgin 2.4.1

No problem with Spark 2.5.8.

Could someone explains the workaround xmpp.fqdn since I added the -Dxmpp.fqdn=true in openfire.vmoptions but same problem.

Also could you provide the settings for pidgin since I wonder if :

  • Domain should be set to server FQN (ie: openfire.mycorp.com) or domain name (mycorp.com)

  • Should I set in advanced TLS/SSL, force old SSL, use clear auth in crypted, use GSSAPI.

Thanks for your help and advices

16

it seems to be a workaround, not a final solution. Anyway, it worked for me too :

  1. go to Server > Server Manager > System Properties

  2. In the page bottom, there is a form, in “Property name” put “xmpp.fqdn” and in “Property value” put your domain name

  3. Restart openfire

This should make pidgin work

17

I’m now using Openfire 3.5.0 and fixed it by using a Sun JVM.

The problem seems to be with some internal security classes not found on IBM Jvm