Project

General

Profile

TLS Negotiation Failure in 5.2.0

Justin Posey
Added almost 5 years ago

A C++ client (tXMPP) is attempting to connect to a Tigase 5.2.0 server we have deployed internally. The connection fails during TLS negotiation. However, the same tXMPP client is able to successfully connect to an older version of Tigase 5.1.0 server deployed to another internal server. TLS is enabled on the client in both scenarios. I've done a bit-level diff of the certificates for Tigase 5.1.0 and Tigase 5.2.0 and they are the same. If we disable TLS on the client, then the connection works fine.

Other standard XMPP clients (PSI and Smack) do not have this problem. Those clients can connect to both servers successfully. So, I know it is something specific to this tXMPP client.

The failure appears to happen because Tigase 5.2.0 does not send complete the "Server Hello Done" portion of the TLS protocol when talking to the tXMPP client. I have attached the 5.1.0 and 5.2.0 packet captures that illustrate the problem. The packet captures are not sending a valid SASL token because we are not testing SASL; we are only testing TLS negotiation at this point.

Any ideas on what could be causing this problem? Thank you!

5.2.0.pcapng (36.7 KB) 5.2.0.pcapng tXMPP --> 5.2.0
5.1.0.pcapng (5.05 KB) 5.1.0.pcapng tXMPP --> 5.1.0

Replies (12)

Added by Justin Posey almost 5 years ago

I see that TLS v1.1 is used in Tigase 5.1.0 and TLS 1.2 is used in Tigase 5.2.0. I suspect that tXMPP cannot handle TLS 1.2. Is there a way to configure Tigase to use TLS 1.1?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

We have done lots of changes to improve security of Tigase server in last versions. We introduced hardened mode which disables all the weak and insecure algorithms and protocols. There were also some changes in the code therefore some clients may behave differently.

However, we discovered there was a bug in code in version 5.2.0-RC1 and earlier which caused some XMPP clients could not connect. This bug has been fixed in 5.2.0-RC2.

Therefore, could you please make sure you use the last available version RC2 if you run from binaries or the current master branch? We started releasing final, the code is tagged already so tomorrow should be available binaries for final 5.2.0.

If this problem still happens with RC2 or final please let me know. We will help you to switch to TLS 1.1 only.

Added by Justin Posey almost 5 years ago

Thank you, Artur. Can you point me to the latest changes so I can ensure I have them included in my 5.2.0 build?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

I cannot point you to specific changes, please use tag for either 5.2.0-RC2 or 5.2.0-final to make sure you include all the fixes.

Added by Justin Posey almost 5 years ago

I am currently using 5.2.0-RC2.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

In such a case we need to find a way to configure Tigase for TLS 1.1 or force it to use TLS 1.1. I think there is a setting for this but I do not remember form the top of my head. I have to ask somebody from our team. He should be able to respond by tomorrow.

Added by Justin Posey almost 5 years ago

Perfect. Thank you!

Avatar?id=6098&size=32x32

Added by Bartosz Malkowski TigaseTeam almost 5 years ago

You may try limit list available protocols (all supported are listed here):

--tls-enabled-protocols=SSLv2Hello,SSLv3,TLSv1,TLSv1.1,TLSv1.2

Do not remove SSLv2Hello!!!!

Added by Justin Posey almost 5 years ago

Hi Bartosz,

Further investigation has shown that the tXMPP client is able to connect with TLSv1.2 on Tigase 5.1.0, but not on Tigase 5.2.0. With Tigase 5.2.0, the server appears to not be sending a "Server Hello Done" as part of the TLS negotiation. For testing, I have changed 5.2.0 init.properties to use the same cipher that is being used by the client and server in 5.1.0:

--hardened-mode=false
--tls-enabled-ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256

You can see in the success packet dump file that the tXMPP client successfully negotiates TLSv1.2 when connecting to 5.1.0. The client and server use the TLS_RSA_WITH_AES_128_CBC_SHA256 cipher.

However, the failure packet dump file shows the tXMPP client fails to negotiate a TLSv1.2 connection when connecting to 5.2.0. 5.2.0 doesn't send the "Server Hello Done" message. The client and server are again using the TLS_RSA_WITH_AES_128_CBC_SHA256 cipher.

I have tried to use an older version of TLS in 5.2.0 and it doesn't work either.

Added by Justin Posey almost 5 years ago

The issue is related to the forcing of BIG_ENDIAN when reading socket data. If I remove the byte ordering logic introduced in 5.2.0, it fixes the issue. Perhaps you can shed some light on why byte re-ordering to big endian is necessary?

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 5 years ago

Byte ordering was introduced to IOService class as we started to use it to support other protocols in other projects based on Tigase XMPP Server. Those protocols required LITTLE_ENDIAN order and knowing that JAVA ByteBuffers are by default created as BIG_ENDIAN, we set default value of order for ByteBuffers used by Tigase XMPP Server to BIG_ENDIAN as changing order from BIG_ENDIAN to BIG_ENDIAN should not make any difference.

Added by Justin Posey almost 5 years ago

Thank you, Andrzej. I see that the TLS RFC indicates that multi-byte data should be delivered in network byte order (big-endian). With that in mind, it sounds like tXMPP is not following the RFC, because changing the incoming byte order to big-endian in Tigase is breaking the tXMPP client. That seems to indicate that tXMPP is delivering it's data in little-endian.

    (1-12/12)