Windows pidgin won't connect to XMPP server after server update; Linux connects

Support
1

The XMPP server Snikket had a new release this year, which I just updated; afterwards, I found that Windows-based pidgin (both 2.14.12 and 2.14.8) refused to connect. Pidgin 2.14.8 on an Ubuntu derivative connected without issues.

The Debug logs from the connection seem to indicate it’s rejecting the authorization methods; the same methods are presented to the Linux-based Pidgin and it accepts them (hostname redacted to reduce my spam load):

(08:43:15) account: Connecting to account art@msg.REDACTED.HOST/.
(08:43:15) connection: Connecting. gc = 05BBBFE8
(08:43:15) dnssrv: querying SRV record for msg.REDACTED.HOST: _xmpp-client._tcp.msg.REDACTED.HOST
(08:43:15) dnssrv: Couldn't look up SRV record. DNS name does not exist. (9003).
(08:43:15) dnsquery: Performing DNS lookup for msg.REDACTED.HOST
(08:43:15) dnsquery: IP resolved for msg.REDACTED.HOST
(08:43:15) proxy: Attempting connection to 129.153.128.163
(08:43:15) proxy: Connecting to msg.REDACTED.HOST:5222 with no proxy
(08:43:15) proxy: Connection in progress
(08:43:15) proxy: Connecting to msg.REDACTED.HOST:5222.
(08:43:15) proxy: Connected to msg.REDACTED.HOST:5222.
(08:43:15) jabber: Sending (art@msg.REDACTED.HOST): <?xml version='1.0' ?>
(08:43:15) jabber: Sending (art@msg.REDACTED.HOST): <stream:stream to='msg.REDACTED.HOST' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(08:43:15) jabber: Recv (388): <?xml version='1.0'?><stream:stream xml:lang='en' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='msg.REDACTED.HOST' xmlns='jabber:client' id='f130eadb-0f82-4b4e-8770-fdd27f9dec26'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls><limits xmlns='urn:xmpp:stream-limits:0'><max-bytes>262144</max-bytes></limits></stream:features>
(08:43:15) jabber: Sending (art@msg.REDACTED.HOST): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(08:43:15) jabber: Recv (50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(08:43:15) nss: SSL version 3.3 using 128-bit AES-GCM with 128-bit AEAD MAC
Server Auth: 2048-bit RSA, Key Exchange: 256-bit ECDHE, Compression: NULL
Cipher Suite Name: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(08:43:15) nss: subject=CN=msg.REDACTED.HOST issuer=CN=R3,O=Let's Encrypt,C=US
(08:43:15) nss: subject=CN=R3,O=Let's Encrypt,C=US issuer=CN=ISRG Root X1,O=Internet Security Research Group,C=US
(08:43:15) nss: subject=CN=ISRG Root X1,O=Internet Security Research Group,C=US issuer=CN=DST Root CA X3,O=Digital Signature Trust Co.
(08:43:15) nss: partial certificate chain
(08:43:15) certificate/x509/tls_cached: Starting verify for msg.REDACTED.HOST
(08:43:15) certificate/x509/tls_cached: Checking for cached cert...
(08:43:15) certificate/x509/tls_cached: ...Found cached cert
(08:43:15) nss/x509: Loading certificate from C:\Users\aes\AppData\Roaming\.purple\certificates\x509\tls_peers\msg.REDACTED.HOST
(08:43:15) certificate/x509/tls_cached: Peer cert matched cached
(08:43:15) nss/x509: Exporting certificate to C:\Users\aes\AppData\Roaming\.purple\certificates\x509\tls_peers\msg.REDACTED.HOST
(08:43:15) util: Writing file C:\Users\aes\AppData\Roaming\.purple\certificates\x509\tls_peers\msg.REDACTED.HOST
(08:43:15) nss: Trusting CN=msg.REDACTED.HOST
(08:43:15) certificate: Successfully verified certificate for msg.REDACTED.HOST
(08:43:15) jabber: Sending (ssl) (art@msg.REDACTED.HOST): <stream:stream to='msg.REDACTED.HOST' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(08:43:15) jabber: Recv (ssl)(1020): <?xml version='1.0'?><stream:stream xml:lang='en' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='msg.REDACTED.HOST' xmlns='jabber:client' id='63a2dfef-7bb6-49b1-b47c-2d05ac13a3ba'><stream:features><authentication xmlns='urn:xmpp:sasl:2'><mechanism>SCRAM-SHA-1-PLUS</mechanism><mechanism>SCRAM-SHA-1</mechanism><inline><bind xmlns='urn:xmpp:bind:0'><inline><feature var='urn:xmpp:carbons:2'/><feature var='urn:xmpp:csi:0'/><feature var='urn:xmpp:sm:3'/></inline></bind><sm xmlns='urn:xmpp:sm:3'/></inline></authentication><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>SCRAM-SHA-1-PLUS</mechanism><mechanism>SCRAM-SHA-1</mechanism></mechanisms><sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'><channel-binding type='tls-unique'/></sasl-channel-binding><register xmlns='urn:xmpp:invite'/><register xmlns='urn:xmpp:ibr-token:0'/><register xmlns='http://jabber.org/features/iq-register'/><limits xmlns='urn:xmpp:stream-limits:0'><max-bytes>262144</max-bytes></limits></stream:features>
(08:43:15) sasl: Mechs found: SCRAM-SHA-1-PLUS SCRAM-SHA-1
(08:43:15) sasl: No worthy mechs found
(08:43:15) connection: Connection error on 05BBBFE8 (reason: 3 description: Server does not use any supported authentication method)
(08:43:15) account: Disconnecting account art@msg.REDACTED.HOST/ (01903D88)
(08:43:15) connection: Disconnecting connection 05BBBFE8
(08:43:15) jabber: Sending (ssl) (art@msg.REDACTED.HOST): </stream:stream>
(08:43:15) connection: Destroying connection 05BBBFE8
(08:43:21) util: Writing file accounts.xml to directory C:\Users\aes\AppData\Roaming\.purple
(08:43:21) util: Writing file C:\Users\aes\AppData\Roaming\.purple\accounts.xml
2

So for whatever reason, the server is saying SCRAM-SHA-1-PLUS and SCRAM-SHA-1 are supported. And SCRAM-SHA-1 should work but obviously isn’t.

Are you able to test this on another windows machine? That shouldn’t make a difference, but would help rule out anything weird with the operating system itself.

3

I have now tried it on a second Windows machine and see the same issue.

4

So I pinged one of the Snikket developers and it looks like the newest version removed the PLAIN SASL mechanism which is completely understandable as they’re aiming for high security.

However, it looks like the SASL library we’re using doesn’t want to use SCRAM-SHA-1 but I’m trying to get something setup so I can reproduce the issue so I can debug it.

5

So I’ve been able to reproduce this, however, everything I’ve done to try to fix it isn’t working and I’m not sure why. So unfortunately it’s going to be a bit here and I’m not sure I’m going to find a decent fix :-/

6

I’m glad you can see it at least. I was able to roll back the server, so that works in the short term.

1 Like
7

Hi, got the same problem. Pidgin 2.14.14 worked on my Windows 7 desktop until the snikket server was updated.
However, both psi and gajim works. Given they both are foss, maybe it is possible to check their implementation.

Is there a way to check what the SASL library thinks which mechanism it is using ? I’m not sure if “Require encryption” means using SCRAM-SHA-1, even though it is an encryption. So, if the authentication first is made with a PLAINtext auth over unencryptes stream, the following stream after auth would still be SCRAM-SHA-1, or is it none if the plaintext method is used? Just asking… Trying to figure out in what order things are done. It would be interresting to see the reason pidgin(sasl library) to why the SCRAM-SHA-1 offer from snikket server is rejected. The log just says “Mech unworthy”.

8

There might be information in the help -> debug window, but you’ll need to open it before attempting to connect.

That said, I think snikket doesn’t allow scram-sha-1 anymore, but scram-sha256 should work and be there.

That said, the output from the debug window will be important here.

9

I’m just asking stupid questions to jog some ideas about what is causing the problem. SCRAM-SHA-1 support was added in version 2.6.6. and it says: “Added support for the SCRAM-SHA-1 SASL mechanism. This is only available when built without Cyrus SASL support.”

How do I know if my pidgin binary is using Cyrus? And is it relevant any longer?

10

I’m pretty sure we build all of the windows binaries with cyrus so if you got it from us directly then it is most likely using it.

So it looks like the version of cyrus-sasl we’re bundling with our windows builds doesn’t have scram-sha-256 support. I’m going to see if I can update that and fire off a test build if you’re interested in testing it.

11

This is going to be harder than I thought, but I’ll keep looking at it.

12

Sure, absolutely! It’s not urgent, but very nice to keep track while working at this host. I checked with allowing PLAIN at the snikket server, and that worked. (no surprise) (disabled it after testing)

13

Well, no worries, great when it happens! At some point I assume it has to happen.

Cyrus-SASL, right?

Would GNU SASL work?

Tempting… maybe I would download the source and see if it is possible to implement G-SASL… Hmmm… Don’t have any tools setup. Not working with Win anylonger… I’m going to take the 5th on that.

14

Yep, watched the debug window many times now. It really does not say more than “No worthy mechs available”. No reason for why it’s rejected.

Yes, snikket allows scram-sha-1, but not with plain text auth by default. It is still possible to enable and allow PLAIN. But why would one if not needed?

15

We’d have to write new code to support GNU SASL. We’re really just trying to do the bare minimum here to keep pidgin 2 running as we get closer to releasing pidgin 3 which is still going to be awhile ™.

1 Like
16

If you trust your transport, it being tls’d or whatever then PLAIN is fine. Many many IRC networks support PLAIN for example.

17

Then keep moving the 3rd pidgin coming!
If I can help to get the 2nd working, I will.

1 Like