cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1357
Views
0
Helpful
4
Replies

XMPP TLS encryption while connecting to port 5222

Adinath
Level 1
Level 1

Hi,

I'm using Cisco Dev Net sandbox (Unified Contact Center Express 12.5-SU1 ) for exploring connection to XMPP port 5222 and 5223.

As I understand 5223 is "old-style TLS"  port where all the communication should be encrypted from the beginning. This is working as expected when I try to connect using my XMPP application. 

But when I connect to 5222, as per rfc6120 - tls I expect to see a mandatory STARTTLS extension in the features sent by server:

 

Step 3: Server sends stream features to client (only the STARTTLS extension at this point, which is mandatory-to-negotiate):

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

 

But for the Cisco UCCX sandbox, I don't see the STARTTLS flow and the client connects over an un-encrypted message stream :

Logs from my XMPP client application:

 

Connecting to server with HostName=hq-uccx.abc.inc, Port=5222

20-10-2022 12:56:16 : To PBX :
<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns='jabber:client' to='hq-uccx.abc.inc' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en-IN'>
20-10-2022 12:56:17 : From PBX :
<stream:features xmlns='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>PLAIN</mechanism></mechanisms><ver xmlns='urn:xmpp:features:rosterver'/><register xmlns='http://jabber.org/features/iq-register'/><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='https://www.igniterealtime.org/projects/openfire/' ver='5mBghvN4pY6xkDxE9K/JMiou5ko='/></stream:features>

 

I have below queries:

  1. Does UCCX 12.5 support TLS (i.e. the STARTTLS flow) over port 5222 ? Is there any configuration setting to enable the same ?
  2. Since the old-style TLS over 5223 might not be supported by all XMPP libraries/client, What is the recommended port to connect to XMPP - 5223 or 5222 ?

 

Best Regards,

Adinath

1 Accepted Solution

Accepted Solutions

@Adinath ,

From the Arktalk.Xmpp code base, I could see that the library doesn't mandate TLS on non-encrypted connections. It relies on the capabilities advertised by the server.  https://github.com/araditc/Artalk.Xmpp/blob/29d8065723d7d1fb0da15c0cf208d3c8982a9e70/Artalk.Xmpp/Core/XmppCore.cs#L719

realexan_0-1666962525501.png

So, as the server is not configured to allow TLS connections on the non-secure port, the client should just proceed without TLS(see 2.2 stream initialization, example 2 for server's behavior here https://xmpp.org/extensions/xep-0035.html).

As you noted, if you want to have a secured connection, you have to connect to port 5223, which is the legacy TLS.

Regarding the SASL authentication mechanism, the server currently supports only PLAIN. It should not be an issue if you are using TLS(port 5223) as the whole payload for the communication gets encrypted, and thus the password in clear text(or base64 encoded) is safe.

Regards,

Renjith

View solution in original post

4 Replies 4

realexan
Cisco Employee
Cisco Employee

Hi @Adinath,

Currently, UCCX doesn't support StartTLS on the insecure notification port, and hence there are no configuration changes that can be made to enable it.

Port 5223 supports conventional TLS, and port 5222(which is disabled by default but can be enabled using a CLI) allows non-encrypted connections. The recommendation is to use the secure port(5223). Generally most(if not all) XMPP clients/libraries can be configured to use the conventional TLS connections rather than going the StartTLS path. Are you using a client that doesn't have this capability?

Regards,

Renjith

Hi Renjith,

We tried to use Artalk.Xmpp client which expects a start-tls flow.

If Cisco supports encrypted traffic only on 5223, then we will have to go with the same  port.

One follow-up question:

The ArTalk library supports these SASL authentication mechanisms: "SCRAM-SHA-1", "DIGEST-MD5", "PLAIN"

The authentication mechanism seen from the logs is always PLAIN. Can we assume that the mechanism will always be PLAIN or it is configurable ??

<stream:features xmlns='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>PLAIN</mechanism></mechanisms><ver xmlns='urn:xmpp:features:rosterver'/><register xmlns='http://jabber.org/features/iq-register'/><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='https://www.igniterealtime.org/projects/openfire/' ver='GBgfrtw1BfrEppPAdTJg='/></stream:features>

 Best Regards,

Adinath

@Adinath ,

From the Arktalk.Xmpp code base, I could see that the library doesn't mandate TLS on non-encrypted connections. It relies on the capabilities advertised by the server.  https://github.com/araditc/Artalk.Xmpp/blob/29d8065723d7d1fb0da15c0cf208d3c8982a9e70/Artalk.Xmpp/Core/XmppCore.cs#L719

realexan_0-1666962525501.png

So, as the server is not configured to allow TLS connections on the non-secure port, the client should just proceed without TLS(see 2.2 stream initialization, example 2 for server's behavior here https://xmpp.org/extensions/xep-0035.html).

As you noted, if you want to have a secured connection, you have to connect to port 5223, which is the legacy TLS.

Regarding the SASL authentication mechanism, the server currently supports only PLAIN. It should not be an issue if you are using TLS(port 5223) as the whole payload for the communication gets encrypted, and thus the password in clear text(or base64 encoded) is safe.

Regards,

Renjith

Thanks for all the info Renjith !!

Best Regards,

Adinath