Opened 10 years ago

Last modified 9 years ago

#7367 new defect

"Old SSL" for XMPP doesn't work

Reported by: Lam Owned by: deryni
Milestone: Component: XMPP
Version: 2.5.2 Keywords:
Cc:

Description (last modified by datallah)

In XMPP, I can't connect to ejabberd server jabster.pl if I force it to use old SSL on port 443 (which for many people is a must, unfortunately). It just hangs pretending to be still connecting. Debug window shows:

(10:26:46) certificate: Successfully verified certificate for jabster.pl
(10:26:46) jabber: Sending (ssl): <?xml version='1.0' ?>
(10:26:46) jabber: Sending (ssl): <stream:stream to='jabster.pl' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(10:26:46) jabber: Recv (ssl)(531): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='1830867428' from='jabster.pl' version='1.0' xml:lang='pl'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><compression xmlns='http://jabber.org/features/compress'><method>zlib</method></compression><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
(10:26:46) jabber: Sending (ssl): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(10:26:46) jabber: Recv (ssl)(50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

I don't understand why does it send starttls if it's already going through SSL. This may me a problem, as when I disable the non-working account that's theoretically still trying to connect (or the server drops inactive connection after two minutes), it says:

(10:34:15) account: Disconnecting account 0x90a6270
(10:34:15) connection: Disconnecting connection 0xa5853a8
(10:34:15) jabber: Sending (ssl): </stream:stream>
(10:34:15) jabber: XML parser error for JabberStream 0xa5362c8: Domain 1, code 5, level 3: Extra content at the end of the document

On the other hand, it _always_ says "extra content" when I disconnect perfectly working GTalk connection, so it's probably not connected.

This is on Fedora 9 and uses NSS, not GnuTLS, if that makes anything different.

Change History (11)

comment:1 Changed 10 years ago by datallah

  • Component changed from unclassified to XMPP
  • Description modified (diff)
  • Owner changed from lschiere to deryni

The "extra content" message isn't a problem.

comment:2 Changed 10 years ago by datallah

It looks like if the server sends a <starttls... we process it regardless of whether we're using the old-style SSL. The RFC doesn't specify what should be done here; perhaps we should ignore it.

comment:3 Changed 10 years ago by deryni

We probably should not attempt to use starttls when we are already connecting over SSL, however I also believe that the server should not be offering a stream feature it cannot correctly complete (and further one that is absolutely incorrect). The last time this issue came up stunnel was involved (#2432). If no such thing is involved here then I would suggest filing a bug with the server software to get them to stop offering starttls when offering stream features over an SSL connection.

comment:4 Changed 10 years ago by bernmeister

deryni: I take your explanation to be this ain't a Pidgin issue...?

comment:5 Changed 10 years ago by darkrain42

  • Milestone set to 2.6.1

There is still work to be done here in Pidgin, although the issue crops up due to buggy server setups.

"fixing" this quirk in libpurple is going to require string changes (to tell the user why we're erroring the connection when the server "requires" SSL), so re-targeting.

comment:6 follow-up: Changed 10 years ago by deryni

Hm... I was going to say this shouldn't require string changes as we should just not attempt to negotiate starttls when we already have an encrypted channel but that opens us up to man-in-the-middle attacks doesn't it?

comment:7 Changed 10 years ago by QuLogic

  • Milestone changed from 2.6.1 to 2.6.2

comment:8 in reply to: ↑ 6 Changed 9 years ago by darkrain42

Replying to deryni:

Hm... I was going to say this shouldn't require string changes as we should just not attempt to negotiate starttls when we already have an encrypted channel but that opens us up to man-in-the-middle attacks doesn't it?

Hmm, I think I was suggesting the only string change needed is for the situation where what we're handling (when the connection is already encrypted) is

<stream:features>
    <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
        <required/>
    </starttls>
    ...
</stream:features>

What MITM attack are you concerned about (and wouldn't there be a certificate mismatch warning in that case)?

comment:9 follow-up: Changed 9 years ago by deryni

Yeah, I'm not sure what I was thinking about exactly. So I think we can ignore it. =)

I'm not sure we can correctly handle this case at all though. If we fail a connection when we are already encrypted and see <starttls><required/></starttls> we will permanently break connections to any broken servers which offer starttls over an encrypted connection and we can never be certain if the connection to the actual server is encrypted (as opposed to a local proxy of some sort) so we can't safely ignore starttls (required or not).

comment:10 in reply to: ↑ 9 Changed 9 years ago by darkrain42

Replying to deryni:

Yeah, I'm not sure what I was thinking about exactly. So I think we can ignore it. =)

I'm not sure we can correctly handle this case at all though. If we fail a connection when we are already encrypted and see <starttls><required/></starttls> we will permanently break connections to any broken servers which offer starttls over an encrypted connection

That's broken as-is, right? This would be no worse (and could offer a decent error message as to why the connection isn't ever going to work).

and we can never be certain if the connection to the actual server is encrypted (as opposed to a local proxy of some sort) so we can't safely ignore starttls (required or not).

This should still present a certificate mismatch warning, unless the enterprise proxying the connection also installs their own CA and adds it to our trust store and signs a cert for, e.g., gmail.com (That's particularly evil). There's no way to know that's ever not the case, though. The best we can tell is that Pidgin thinks the connection is encrypted and the server strangely doesn't. Perhaps we should throw up a warning prompt about a possible MITM?

If we can't pay attention to starttls and fail the connection and we can't safely ignore starttls, what are you suggesting we do? :-)

comment:11 Changed 9 years ago by darkrain42

  • Milestone 2.6.2 deleted
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!