Opened 12 years ago

Closed 11 years ago

#2432 closed defect (wontfix)

Pidgin is not connecting when using XMPP under special conditions

Reported by: Valgoerad Owned by: deryni
Milestone: Component: XMPP
Version: 2.1.0 Keywords:


I'm trying to use Pidgin at work where I have only couple of ports open. I have created a tunnel on port 443 for XMPP and everything works correctly when using Pandion or PSI but Pidgin has some problems unfortunately.

I have created a new XMPP account, specified my own connect port, connect server and checked "Force old SSL". But with these options set-up I get:

(14:17:12) account: Connecting to account
(14:17:12) connection: Connecting. gc = 022C4BC0
(14:17:12) dnsquery: Performing DNS lookup for
(14:17:12) dnsquery: IP resolved for
(14:17:12) proxy: Attempting connection to
(14:17:12) proxy: Connecting to with no proxy
(14:17:12) proxy: Connection in progress
(14:17:12) proxy: Connected to
(14:17:12) jabber: Sending (ssl): <?xml version='1.0' ?>
(14:17:12) jabber: Sending (ssl): <stream:stream to='' xmlns='jabber:client' xmlns:stream='' version='1.0'>
(14:17:12) jabber: Recv (ssl)(435): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='' id='3676372883' from='' version='1.0' xml:lang='en'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><register xmlns=''/></stream:features>
(14:17:12) jabber: Sending (ssl): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(14:17:12) jabber: Recv (ssl)(50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

As you can see form the script above, Pidgin connects to the server, talks to it and then fails to proceed with tls encryption. It just hangs there for eternity. I'm not sure if tls should even be used when using SSL but you're the experts so I'll leave it up to you :)

You're doing a great job, guys - there's really no superior alternative for Pidgin. Thanks.

Change History (12)

comment:1 Changed 12 years ago by deryni

  • pending changed from 0 to 1

If you turn off force ssl I'm assuming the connection fails? Correct? Can you get the psi (and pandion) xml traffic from when they connect successfully?

I don't believe tls should be being offered when already connected via ssl though I am could very well be mistaken (though I doubt it as that would be very odd).

comment:2 Changed 12 years ago by Valgoerad

  • pending changed from 1 to 0

Psi uses colors to mark outgoing and incoming messages in it's own XML console so it will be a bit harder to read since there are no colors present here obviously. But I hope it will prove sufficient.

PSI output:

<?xml version="1.0"?>

<stream:stream xmlns:stream="" version="1.0" xmlns="jabber:client" to="" xml:lang="en" xmlns:xml="" >

<?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='' id='3722030807' from='' version='1.0' xml:lang='en'>

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<register xmlns=""/>

<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5" />

<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">bm9uY2(...)</challenge>

<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dXNlcm5hbWU9(...)</response>

<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">cnNwYXV0aD0(...)</challenge>

<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

<?xml version="1.0"?>

<stream:stream xmlns:stream="" version="1.0" xmlns="jabber:client" to="" xml:lang="en" xmlns:xml="" >

<?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='' id='855998014' from='' version='1.0' xml:lang='en'>

<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
<session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>

<iq type="set" id="bind_1" >
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">

<iq xmlns="jabber:client" type="result" id="bind_1" >
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">

<iq type="set" id="aac3a" >
<session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>

<iq type="result" id="aac3a" >
<session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>

<iq type="get" id="aac4a" >
<query xmlns="jabber:iq:roster"/>

comment:3 Changed 12 years ago by Valgoerad

Oh, forgot about the "Force" part. Yes, connection fails when force ssl is turned off.

Furthermore, I can't provide any XML output of Pandion since it doesn't have debug option visible. Or I just can't find the thing.


comment:4 Changed 12 years ago by deryni

Yeah, that's about what I figured, psi isn't trying to starttls and pidgin is. I'm pretty sure offering starttls over an already ssl:ed connection is not a valid thing to do, though I'm not sure the spec talks about it (I would have to check and don't have the time right now). I suspect your server is being broken when it offers it over the ssl stream. What server software is this using, do you know?

comment:5 Changed 12 years ago by Valgoerad

Yes, I know what server software it is using - it's ejabberd 1.1.2. Actually I have it under my care so if you need any logs don't hesitate to ask. I haven't enabled any debug yet, but when yo try to access the account using Pidgin, you get:

=INFO REPORT==== 7-Aug-2007::10:07:49 ===
I(<0.223.0>:ejabberd_listener:90): (#Port<0.576399>) Accepted connection {{62,233,139,74},42721} -> {{62,233,139,74},5222}

And that's all. No errors present.

Now, when you connect from PSI:

=INFO REPORT==== 7-Aug-2007::10:09:10 ===
I(<0.223.0>:ejabberd_listener:90): (#Port<0.576403>) Accepted connection {{62,233,139,74},42727} -> {{62,233,139,74},5222}

=INFO REPORT==== 7-Aug-2007::10:09:10 ===
I(<0.14703.13>:ejabberd_c2s:601): (#Port<0.576403>) Accepted authentication for martel

=INFO REPORT==== 7-Aug-2007::10:09:10 ===
I(<0.14703.13>:ejabberd_c2s:696): (#Port<0.576403>) Opened session for

And Pandion:

=INFO REPORT==== 7-Aug-2007::10:09:46 ===
I(<0.223.0>:ejabberd_listener:90): (#Port<0.576461>) Accepted connection {{62,233,139,74},42737} -> {{62,233,139,74},5222}

=INFO REPORT==== 7-Aug-2007::10:09:46 ===
I(<0.14729.13>:ejabberd_c2s:382): (#Port<0.576461>) Accepted legacy authentication for

comment:6 Changed 12 years ago by deryni

Do you have port 443 (or whatever you have that forwarded to) on the ejabberd set up in the config as an ssl or tls port? If you have it set up as tls try switching to ssl and seeing if that fixes it.

comment:7 Changed 12 years ago by deryni

Oh, actually having looked at your logs more closely it looks like you are connecting to 5222 which (unless you have changed the defaults) should be set up as tls, so yeah, try setting it to use ssl and/or having proxied connections hit 5223 (which is by default set up as ssl, and as such won't break normal people connecting).

comment:8 Changed 12 years ago by Valgoerad

I have managed to get it working by getting rid of stunnel and configuring ejabberd to listen on port 443.

I guess I don't understand fully how stunnel works. I have assumed it creates SSL connection on listening port 443 - where I'm connecting to with Jabber using SSL. And then stunnel forwards my connection to port 5222 with unencrypted line (switching stunnel to 5223 makes every client unable to connect).

I still think it's some kind of a bug when it comes to force old ssl. I'll try to test it at home where I can try connecting to 5223 directly.

comment:9 Changed 12 years ago by deryni

stunnel sets up an encrypted connection to an unencrypted port, which is why ejabberd was offering starttls over it (unfortunately starttls over an already encrypted connection makes no sense) which is why pidgin was failing and psi/pandion were working. A direct proxy from 443 to 5223 would work with old SSL because the proxy would just forward packets, stunnel negotiates its own SSL connection. Though why pidgin is responding to starttls over an SSL link I am not at all sure, it probably shouldn't (assuming that is in fact not valid).

In summary: plain or starttls directly to 5222, ssl to 5223, proxy across to either, stunnel to 5222 (without starttls).

comment:10 Changed 12 years ago by datallah

  • Component changed from winpidgin (gtk) to libpurple
  • Owner changed from datallah to deryni

comment:11 Changed 12 years ago by seanegan

  • Component changed from libpurple to XMPP

comment:12 Changed 11 years ago by deryni

  • Resolution set to wontfix
  • Status changed from new to closed

I was leaving this open in case I decided to try to work around this correctly, I think I know what needs to be done and I think it is just a one line change but I'm not sure it is correct in all cases and I don't really think I feel like testing things that carefully. I also think the configuration here which triggered this bug was not a configuration that should really be used so I'm going to close this as wontfix and if this comes up again I'll think about it again.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!