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

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
(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='' version='1.0'>
(08:43:15) jabber: Recv (388): <?xml version='1.0'?><stream:stream xml:lang='en' version='1.0' xmlns:stream='' 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='' version='1.0'>
(08:43:15) jabber: Recv (ssl)(1020): <?xml version='1.0'?><stream:stream xml:lang='en' version='1.0' xmlns:stream='' 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=''/><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

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.

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

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.

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 :-/

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