Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#1435 closed defect (fixed)

server handshake failes due to cipher spec mismatch

Reported by: bastischubert Owned by: deryni
Milestone: 2.5.2 Component: libpurple
Version: 2.0.1 Keywords: cipher specs
Cc: ari, darkpixel

Description

while trying to connect to an xmpp server i get an handshake error

debug version shows the following output when connecting to 5222 and using starttls:

(23:28:09) account: Connecting to account bauchilein@im.lokalisten.de/pidgin
(23:28:09) connection: Connecting. gc = 03A4B780
(23:28:09) dnsquery: Performing DNS lookup for im.lokalisten.de
(23:28:09) dnsquery: IP resolved for im.lokalisten.de
(23:28:09) proxy: Attempting connection to 194.97.153.82
(23:28:09) proxy: Connecting to im.lokalisten.de:5222 with no proxy
(23:28:09) proxy: Connection in progress
(23:28:09) proxy: Connected to im.lokalisten.de:5222.
(23:28:09) jabber: Sending: <?xml version='1.0' ?>
(23:28:09) jabber: Sending: <stream:stream to='im.lokalisten.de' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(23:28:09) jabber: Recv (521): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="im.lokalisten.de" id="d41dba2a" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features>
(23:28:09) jabber: Sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(23:28:09) jabber: Recv (50): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
(23:28:09) nss: Handshake failed -5938
(23:28:09) account: Disconnecting account 00D53DA8
(23:28:09) connection: Disconnecting connection 03A4B780
(23:28:09) connection: Destroying connection 03A4B780

trying the same with port 5223 and direct ssl connect

(23:34:12) account: Connecting to account bauchilein@im.lokalisten.de/pidgin
(23:34:12) connection: Connecting. gc = 00D72D28
(23:34:12) dnsquery: Performing DNS lookup for im.lokalisten.de
(23:34:12) dnsquery: IP resolved for im.lokalisten.de
(23:34:12) proxy: Attempting connection to 194.97.153.82
(23:34:12) proxy: Connecting to im.lokalisten.de:5223 with no proxy
(23:34:12) proxy: Connection in progress
(23:34:12) proxy: Connected to im.lokalisten.de:5223.
(23:34:12) nss: Handshake failed -12286
(23:34:12) account: Disconnecting account 00D53978
(23:34:12) connection: Disconnecting connection 00D72D28
(23:34:12) connection: Destroying connection 00D72D28

Tested with Pidgin 2.0.1 on Windows and CentOS/Linux

The following cipher specs are offered from the client according to wireshark:

SSLv2 Record Layer: Client Hello
Length: 70
Handshake Message Type: Client Hello (1)
Version: TLS 1.0 (0x0301)
Cipher Spec Length: 45
Session ID Length: 0
Challenge Length: 16
Cipher Specs (15 specs)
Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080)
Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040)
Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)
Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080)
Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
Cipher Spec: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0x00feff)
Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
Cipher Spec: SSL_RSA_FIPS_WITH_DES_CBC_SHA (0x00fefe)
Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009)
Cipher Spec: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x000064)
Cipher Spec: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x000062)
Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003)
Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006)
Challenge

the specs seem a bit "weak" imho :-/
any ideas?

Change History (23)

comment:1 Changed 12 years ago by lschiere

  • Milestone set to 2.1.2
  • Owner set to nwalp

comment:2 Changed 12 years ago by seanegan

  • Component changed from pidgin (gtk) to libpurple

comment:3 Changed 11 years ago by jberger

Is there any progress on this ticket? I think this bug should have a higher priority, because it completely prevents connections to some Jabber servers, like amessage.de.

A patch can be found here: http://www.nabble.com/Pidgin-cannot-connect-to-amessage.de-using-TLS-secured-XMPP-td17059290.html

comment:4 follow-ups: Changed 11 years ago by deryni

  • Owner changed from nwalp to deryni

The priority field doesn't mean what you think it means, so don't worry about that. This ticket hasn't received much attention because we haven't heard too many people complaining about it and I haven't had the time (nor do I, at the moment, have the knowledge) to correctly work on this issue. The "But please consider that this may break other SSL connections, the new "SSL Client Hello" message does not look SSLv2-compatible any more" part of the email with the patch gives me some small concerns about applying the patch (though perhaps it should not, again I'm not too familiar with this sort of thing). I will attempt to get to this (and have people a bit more familiar with this sort of thing look at it) soon.

comment:5 in reply to: ↑ 4 Changed 11 years ago by ErnstRohlicek

Replying to deryni:

Why do you only activate weak ciphers by default? What's the point of feeling secure when in fact it's using just weak (= pracitally no) encryption?

This ticket hasn't received much attention because we haven't heard too many people complaining about it [...]

Anyway, I am one of these guys affected by it. Including the patch in the next release would be cool.

Greetings, Ernst Rohlicek jun.

comment:6 Changed 11 years ago by deryni

As indicated in the nabble link posted pidgin is not "only activat[ing] weak ciphers by default" it is enabling the NSS defaults for the Domestic Policy setting. That setting appears not to include a number of ciphers which amessage seems to require.

Also, I would like to point out (since I failed to last time) that we were entirely unaware of the existance of the patch until it was brought to our attention in this ticket on July 12th. Nabble apparently did not actually submit it to our mailing list despite it being a response to a mailing list post.

comment:7 Changed 11 years ago by candrews

Any news on this? It affects my corporate XMPP server too, really putting a damper on pidgin. Thanks!

comment:8 in reply to: ↑ 4 Changed 11 years ago by peachris

Replying to deryni:

This ticket hasn't received much attention because we haven't heard too many people complaining about it and I haven't had the time (nor do I, at the moment, have the knowledge) to correctly work on this issue.

If it helps motivate you brave developers, then please let me complain. I have been locked out of amessage.info for months now, and lost contact to some friends as a consequence. No, I refuse to use any other IM client! Please fix this soon.

comment:9 Changed 11 years ago by candrews

This really is a Big Deal. I can definitely see services like GTalk requiring strong ciphers at any time, and Pidgin users would be left out. And lots of corporate environments, like mine, require strong ciphers, really damaging pidgin adoption. For every comment on here, I bet there are many many more users who simple say, "Pidgin doesn't work - I'll just use GTalk/Trillian/Adium/..." This bug is really painful, and can even be considered a security vulnerability. Please please fix it.

comment:10 Changed 11 years ago by elb@…

  • Milestone set to 2.5.2
  • Resolution set to fixed
  • Status changed from new to closed

(In 475223945bc39fa8d35f30060dd5cfda787d82d5):
Enable a number of default-disabled strong ciphers for NSS.

For some reason the NSS default US Domestic policy does not enable a number of strong ciphers which are entirely reasonable, and in fact may be preferred. (E.g. those using SHA over MD5.)

This patch enables all available AES, 3DES, and RC4 ciphers which are not enabled by default.

Thanks to Marcus Trautwig for this.

Fixes #1435

comment:11 Changed 11 years ago by candrews

Thanks indeed! This is great news - this was a big problem for me, and I really appreciate it being addressed. Go Pidgin!

comment:12 Changed 11 years ago by ErnstRohlicek

Thanks from me too! Looking forward to get into amessage and others again :-)

comment:13 Changed 11 years ago by elb

Those who wish to patch their 2.5.1 or earlier versions of Pidgin may click the revision number in the commit message and download the diff from there. Hopefully 2.5.2 will be out soonish (probably the next couple of weeks) with this, and other, changes.

comment:14 Changed 11 years ago by stefanx

I was happy to tryout Pdigin 2.5.2 which should fix this problem. Unfortunately connecting to my Jabber account (ejabberd) through port 5222 (new TLS protocol) still fails. Here is the debug log:

---

(15:01:49) account: Connecting to account stefan@…/Home (15:01:49) connection: Connecting. gc = 03728510 (15:01:49) dnsquery: Performing DNS lookup for jabber.example.com (15:01:49) dnsquery: IP resolved for jabber.example.com (15:01:49) proxy: Attempting connection to 84.19.xxx.yyy (15:01:49) proxy: Connecting to jabber.example.com:5222 with no proxy (15:01:49) proxy: Connection in progress (15:01:49) proxy: Connected to jabber.example.com:5222. (15:01:49) jabber: Sending: <?xml version='1.0' ?> (15:01:49) jabber: Sending: <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> (15:01:49) jabber: Recv (21): <?xml version='1.0'?> (15:01:50) jabber: Recv (365): <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='287236560' from='example.com' version='1.0' xml:lang='en'><stream:features><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> (15:01:50) account: Disconnecting account 00CD9708 (15:01:50) connection: Disconnecting connection 03728510 (15:01:50) jabber: XML parser error for JabberStream? 036BBA00: Domain 1, code 5, level 3: Extra content at the end of the document (15:01:50) jabber: jabber_actions: have pep: NO (15:01:50) connection: Destroying connection 03728510

---

My ejabberd server tells me "Accepted connection".

comment:15 Changed 11 years ago by deryni

Your error doesn't look related to the error in this ticket. Was your version of pidgin built with Cyrus SASL support (the About window will say)? If so, do you have the digest-md5 and/or plain SASL modules installed on your system.

comment:16 Changed 11 years ago by stefanx

Yes, my version of pidgin is built with Cyrus SASL support (Windows-binaries form pidgin website).

Which modules are you talking about? Intentionally I did not installed any additional modules for Pidgin beside of what the Pidgin-installer installed. How can I find these modules?

comment:17 Changed 11 years ago by deryni

Windows comes with the correct SASL modules, you don't need to install anything by hand.

Do you have the 'Require TLS' checkbox selected for the account? If so, do you see an error message in the bottom of the buddy list when pidgin fails to connect your account? One that says that you require TLS but the server doesn't support it? The debug log you posted shows that the server is not offering TLS as an option.

comment:18 Changed 11 years ago by stefanx

Yes I have the check box "require TLS" selected. In this case I get the message "Sie fordern Verschlüsselung, aber diese ist auf dem Server nicht verfügbar" which means "you require encryption which is not supported by the server".

Encrypted connection with Gajim to the same port (5222) works fine.

Any idea?

comment:19 Changed 11 years ago by deryni

One of two things is happening when gajim connects. Either it tries a TLS connection without checking if the server supports it (which is absolutely broken behavior and seems unlikely to me) or gajim is intending to use TLS when it starts the connection, discovers that the server doesn't support it and (either silently or in a way you don't notice) falls back to not using TLS and continues normally.

Your selection of the 'require TLS' option prevents pidgin from falling back to using a non-TLS connection to the server when it determines that the server doesn't support it, thus the error message you are receiving.

If gajim has a debug/xml log you may be able to check that to see if it is in fact negotiating a TLS connection or not, if it doesn't or it doesn't indicate one way or the other than a tool like wireshark will tell you.

There is actually one other possibility, which is that gajim is in fact using port 5223 and and old-style SSL connection rather than using starttls over 5222.

comment:20 Changed 11 years ago by stefanx

Please check the following Gajim log:

<?xml version='1.0'?>
<stream:stream xmlns="jabber:client" to="example.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" >

<?xml version='1.0'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='1769693020' from='example.com' version='1.0' xml:lang='en'>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<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>

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

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

<?xml version='1.0'?>
<stream:stream xmlns="jabber:client" to="example.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" >

<?xml version='1.0'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='980616346' from='example.com' version='1.0' xml:lang='en'>

<stream:features>
<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>

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

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>bm9uY2U9IjM5NjU3MDA0NDciLHFvcD0iYXV0aCIsY2hhcn...</challenge>

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

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>cnNwYXV0aD1mZDIyOTA1YjdmY2VlMTlmNDZhMzM5NjA1YTQ3...</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="jabber:client" to="example.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" >

One of two things is happening when gajim connects. Either it tries a TLS connection without checking if the server supports it (which is absolutely broken behavior and seems unlikely to me) or gajim is intending to use TLS when it starts the connection, discovers that the server doesn't support it and (either silently or in a way you don't notice) falls back to not using TLS and continues normally.

For me the log seems to look as Gajim would really use TLS and has no problem with "TLS-required".

Your selection of the 'require TLS' option prevents pidgin from falling back to using a non-TLS connection to the server when it determines that the server doesn't support it, thus the error message you are receiving.

While I definitely want an encrypted connection a failed connection rather than an unencrypted connection is fine. But I don't see why my server doesn't support TLS.

There is actually one other possibility, which is that gajim is in fact using port 5223 and and old-style SSL connection rather than using starttls over 5222.

I configured Gajim to use port 5222.

Any ideas?

comment:21 Changed 11 years ago by deryni

Did that Gajim log come from the same server the pidgin log you posted before came from? Because this log does advertise the starttls feature whereas the one before did not.

The pidgin log:

Send
----
<?xml version='1.0' ?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

Receive
-------
<?xml version='1.0'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='287236560' from='example.com' version='1.0' xml:lang='en'>
    <stream:features>
        <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>

The gajim log:

Send
----
<?xml version='1.0'?>
<stream:stream xmlns="jabber:client" to="example.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" >

Receive
-------
<?xml version='1.0'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='1769693020' from='example.com' version='1.0' xml:lang='en'>
    <stream:features>
        <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
            <required/>
        </starttls>
        <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>

See the difference in the stream features?

I have no idea what could be causing the server to be sending the starttls stream feature to one client and not to another, if in fact both logs are from the same server and pidgin is still not working while gajim continues to work.

comment:22 Changed 11 years ago by stefanx

Thanks for your help!

I double checked: both logs are from the same server, same port.

What about the XML parser error which appeared in Pidgin? May this be relevant?

Probably I should discuss this problem with the ejabberd (server) people.

comment:23 Changed 11 years ago by deryni

You can ignore the extra content at end of document errors in the pidgin log, they shouldn't affect anything.

Is the server you are testing this with a publicly facing server? Would it be possible for me to test with? Could you test with some other client that has an xml console (just so we could get another sample to compare)?

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!