10-20-2022 12:54 AM - edited 10-20-2022 07:54 AM
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:
Best Regards,
Adinath
Solved! Go to Solution.
10-28-2022 06:22 AM - edited 10-28-2022 08:43 AM
@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
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
10-28-2022 02:27 AM
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
10-28-2022 04:44 AM
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
10-28-2022 06:22 AM - edited 10-28-2022 08:43 AM
@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
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
10-31-2022 05:13 AM
Thanks for all the info Renjith !!
Best Regards,
Adinath
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide