Can' connect to pubsub

[mimi89999]

Jul 28 21:46:42 lebihan.pl:tls	debug	pubsub.chatsecure.org is offering TLS, taking up the offer...
Jul 28 21:46:42 s2sout1cbc560	debug	sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Jul 28 21:46:42 s2sout1cbc560	debug	Received[s2sout_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Jul 28 21:46:42 lebihan.pl:tls	debug	Proceeding with TLS on s2sout...
Jul 28 21:46:42 socket	debug	server.lua: attempting to start tls on tcp{client}: 0xe35a38
Jul 28 21:46:42 c2sc7d8e8	debug	Received[c2s]: <a xmlns='urn:xmpp:sm:3' h='668'>
Jul 28 21:46:42 c2sc7d8e8	debug	#queue = 0
Jul 28 21:46:42 socket	debug	server.lua: ssl handshake error: sslv3 alert handshake failure
Jul 28 21:46:42 s2sout1cbc560	debug	s2s connection attempt failed: ssl handshake error: sslv3 alert handshake failure
Jul 28 21:46:42 s2sout1cbc560	info	Failed in all attempts to connect to pubsub.chatsecure.org
Jul 28 21:46:42 mod_s2s	debug	No other records to try for pubsub.chatsecure.org - destroying
Jul 28 21:46:42 s2sout1cbc560	debug	Destroying outgoing session lebihan.pl->pubsub.chatsecure.org: Connecting failed: ssl handshake error: sslv3 alert handshake failure

@chrisballinger Could you please investigate what's going on with the server?

[chrisballinger]

Possibly because your server requires a peer cert?

[chrisballinger]

Here's our server reports:

• https://check.messaging.one/result.php?id=19246
• https://check.messaging.one/result.php?id=19248

[Zash]

If @mimi89999 s server takes issue with something, it would probably be the one aborting the connection. Here it's the chatsecure one aborting it. If you have logs that capture anything from the TLS negotiation, that's where I would look if I were you.

[Zash]

Attempting to connect with no non-forward-secret ciphers enabled, it fails. Using Prosody default ciphers, AES256-GCM-SHA384 is selected.

[chrisballinger]

Our server has no logs which makes this kind of hard to debug....

[mimi89999]

Curves are the issue here. Prosody is using secp384r1, but pubsub chatsecure is using prime256v1. That's why ECDHE isn't negotiated.

[chrisballinger]

Aha! How did you figure that out?

[mimi89999]

After @Zash said that plain RSA gets negotiated for him, I started looking why could ECDHE not get negotiated. I looked at the messaging one report and saw that different primes are used.

[chrisballinger]

Why isn't this something that is handled during cipher negotiation? Sigh..

[Zash]

It is handled, but the exact behavior has changed in OpenSSL and/or LuaSec in a way that complicates things. Before, it was treated more like how normal DH is treated; the server decides and the client just goes along with it. Now, it works more like ciphers, each party has a ordered set and something out of the intersection gets selected to be used. But due to the earlier behavior, the set of curves is just a single one so unless both ends use the exact same curve the connection either gets aborted, or it picks a different cipher suite.

[mimi89999]

@chrisballinger @Zash I resolved the issue by enabling non FS ciphersuites, but I am not happy with that...

[chrisballinger]

@mimi89999 I agree that's not ideal. I'd like to disable non-FS as well but if it breaks everyone using the wrong curve, that's a dealbreaker... :-\

[mimi89999]

everyone using the wrong curve

Storm about which curve is right started? 😄

It's good to also support DH... Maybe I will install the latest version of luasec from upstream. It should support multiple curves...

[dholl]

+1 for including a DHE backup cipher for pubsub.chatsecure.org, at least as a workaround for incompatible ECDHE curves, Please? :)

Here's my cipher list:
https://check.messaging.one/result.php?id=115427#ciphers

My rationale for requesting a DHE backup cipher, even though it is more overhead than ECDHE:

Some XMPP servers use prime256v1, and others use secp384r1, including my system (running Prosody 0.10.0-1 Debian). Is it possible for me to configure my system to negotiate with both prime256v1 and secp384r1 systems? If not, then would including a DHE cipher (lower down in your list if you wish) be an all right option to include so that third party operators (like myself) also don't need to enable non-FS ciphers?

Or must I throw in AES256-GCM-SHA384 as my last-resort backup in my own cipher list? :)

I stumbled upon this curve incompatibility issue in diagnosing my own system's failure to support push notifications (#770) for an iPhone friend. (hooray for debug messages)

Mar 07 23:14:51 ad5ey.net:tls          debug pubsub.chatsecure.org is offering TLS, taking up the offer...
Mar 07 23:14:51 s2sout5564652e18f0     debug sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Mar 07 23:14:51 s2sout5564652e18f0     debug Received[s2sout_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Mar 07 23:14:51 ad5ey.net:tls          debug Proceeding with TLS on s2sout...
Mar 07 23:14:51 socket                 debug server.lua: attempting to start tls on tcp{client}: 0x5564656c3978
Mar 07 23:14:51 socket                 debug server.lua: ssl handshake error: sslv3 alert handshake failure
Mar 07 23:14:51 s2sout5564652e18f0     debug s2s connection attempt failed: ssl handshake error: sslv3 alert handshake failure
Mar 07 23:14:51 s2sout5564652e18f0     info  Failed in all attempts to connect to pubsub.chatsecure.org
Mar 07 23:14:51 mod_s2s                debug No other records to try for pubsub.chatsecure.org - destroying
Mar 07 23:14:51 s2sout5564652e18f0     debug Destroying outgoing session ad5ey.net->pubsub.chatsecure.org: Connecting failed: ssl handshake error: sslv3 alert handshake failure
Mar 07 23:14:51 s2sout5564652e18f0     info  Sending error replies for 1 queued stanzas because of failed outgoing connection to pubsub.chatsecure.org
Mar 07 23:14:51 stanzarouter           debug Received[s2sin]: <iq id='9fbd30cea06e740f55759d3e8d08d4b9ad08dc99e53e26d5cadf2aef5c5961ca' type='error' to='ad5ey.net' from='pubsub.chatsecure.org'>
Mar 07 23:14:51 ad5ey.net:cloud_notify info  Got error of type 'cancel' (remote-server-not-found) for identifier 'pubsub.chatsecure.org<E10BF36C-3B8A-4D7A-99A5-A1137C17263C': error count for this identifier is now at 2

[dholl]

So I added AES256-GCM-SHA384 to my ciphers list (at the bottom...), and that fixed push notifications.

@chrisballinger - Are you the admin for pubsub.chatsecure.org? What do you think about enabling some DHE ciphers as backups for ECDHE curve incompatibilities? Then we could still have forward secrecy... (Pretty please?) :)

[dholl]

nudge nudge... Any chance of supporting DHE ciphers on pubsub.chatsecure.org, pretty please? :)

Feel free to put them at the bottom of your cipher list if that's your preference, but it'd be swell to provide a work around for ECDHE curve incompatibilities across the whole community of XMPP servers...

For anyone else, here's my config snippet for Prosody 0.10.2 (from Debian packages) for a mostly-PFS cipher list with AES256-GCM-SHA384 at the end to interoperate with pubsub.chatsecure.org:

ssl = {
        -- tweak to your heart's content:
        -- key = "/blah/blah/blah.key";
        -- certificate = "/blah/blah/blah.crt";
        -- capath = "/etc/ssl/certs";
        dhparam = "/etc/prosody/dhparam.pem"; -- regenerated monthly via sh -c "openssl dhparam -out dhparam.tmp 2048 && mv dhparam.tmp dhparam.pem && chmod 644 dhparam.pem && /etc/init.d/prosody reload"
        ciphers = "HIGH+EDH:HIGH+EECDH:+RSA:+ECDSA:@STRENGTH:+SHA384:+SHA256:+SHA1:!aNULL:!eNULL:!DSS:!3DES:!DES:!RC4:!LOW:!EXP:AES256-GCM-SHA384";
        -- protocol = "tlsv1_1+";
}

[sebastiansterk]

@chrisballinger any updates on this topic?