Not logged in. · Lost password · Register
Forum: MatriX and XmppDotNet RSS
Cause of server not requiring Start-Tls
Avatar
SimonBrinkmann 2016-11-23, 14:55 #1
Member since Sep 2013 · 7 posts · Location: Norway
Group memberships: Members
Show profile · Link to this post
Subject: Cause of server not requiring Start-Tls
I have an issue where 2 clients register to the same Cisco IM & Presence from the same process/application. The first client1 is required starttls and offered two Sasl-Mechanisms but  client2 registering is NOT required to send starttls and is only offered PLAIN as sasl mechanism.

I also remark that the client2 is not reusing the stream (different stream id's)

If I switch the clients so that client2 is registering first I get the that client2 has starttls required and offered 2 sasl-mechanisms and client1 only gets 1 sasl-mechanism.

Any ideas what might cause this behavior?


Client1 correct registration
  1. S = Client send
  2. R = Client Received
  3. E = Event in Matrix
  4.  
  5.  
  6. S:
  7. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="mycompany.org" version="1.0" >
  8.  
  9. R:
  10. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" xml:lang="en-US.UTF-8" id="28BC104F770C" from="mycompany.org" version="1.0" >
  11.  
  12. R:
  13. <stream:features xmlns:stream="http://etherx.jabber.org/streams">
  14.  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls">
  15.     <required />
  16.  </starttls>
  17. </stream:features>
  18.  
  19. S:
  20. <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  21.  
  22. R:
  23. <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  24.  
  25. S:
  26. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="mycompany.org" version="1.0" >
  27.  
  28. R:
  29. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" xml:lang="en-US.UTF-8" id="28BC104F770C" from="mycompany.org" version="1.0" >
  30.  
  31. R:
  32. <stream:features xmlns:stream="http://etherx.jabber.org/streams">
  33.  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  34.     <mechanism>PLAIN</mechanism>
  35.     <mechanism>CISCO-VTG-TOKEN</mechanism>
  36.  </mechanisms>
  37. </stream:features>
  38.  
  39. E: OnBeforeSasl
  40.  
  41. S:
  42. <auth mechanism="CISCO-VTG-TOKEN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">auth-token-removed-in-log</auth>
  43.  
  44. R:
  45. <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
  46.  
  47. E: OnLogin
  48.  
  49. S:
  50. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="mycompany.org" version="1.0" >
  51.  
  52. R:
  53. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" xml:lang="en-US.UTF-8" id="28BC104F770C" from="mycompany.org" version="1.0" >
  54.  
  55. R:
  56. <stream:features xmlns:stream="http://etherx.jabber.org/streams">
  57.  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind" />
  58.  <session xmlns="urn:ietf:params:xml:ns:xmpp-session" />
  59.  <sm xmlns="urn:xmpp:sm:3">
  60.     <optional />
  61.  </sm>
  62.  <mdm xmlns="http://protocols.cisco.com/mdm:1">
  63.     <optional />
  64.  </mdm>
  65. </stream:features>
  66.  
  67. E: OnBindStart
  68.  
  69. S:
  70. <iq id="MX_1" type="set" xmlns="jabber:client">
  71.  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  72.     <resource>myResource</resource>
  73.  </bind>
  74. </iq>
  75.  
  76. R:
  77. <iq id="MX_1" type="result" xmlns="jabber:client">
  78.  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  79.     <jid>myUser@mycompany.org/myResource</jid>
  80.  </bind>
  81. </iq>
  82.  
  83. E: OnBind
  84.  
  85. S:
  86. <iq id="MX_2" type="set" xmlns="jabber:client">
  87.  <session xmlns="urn:ietf:params:xml:ns:xmpp-session" />
  88. </iq>
  89.  
  90. R:
  91. <iq id="MX_2" type="result" xmlns="jabber:client" />
  92.  
  93. S:
  94. <presence xmlns="jabber:client">
  95.  <status></status>
  96.  <priority>0</priority>
  97. </presence>
  98.  
  99. R:
  100. <presence from="myUser@mycompany.org/myResource" to="myUser@mycompany.org" xmlns="jabber:client">
  101.  <status />
  102.  <priority>0</priority>
  103. </presence>


Client2 without starttls required and only 1 sasl-mechanism
  1. S:
  2. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="mycompany.org" version="1.0" >
  3.  
  4. R:
  5. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="mycompany.org" id="720bae45d920d238" version="1.0" >
  6.  
  7. R:
  8. <stream:features xmlns:stream="http://etherx.jabber.org/streams">
  9.  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  10.  <compression xmlns="http://jabber.org/features/compress">
  11.     <method>zlib</method>
  12.  </compression>
  13.  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  14.     <mechanism>PLAIN</mechanism>
  15.  </mechanisms>
  16. </stream:features>
  17.  
  18. S:
  19. <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  20.  
  21. R:
  22. <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  23.  
  24. S:
  25. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="mycompany.org" version="1.0" >
  26.  
  27. R:
  28. <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="mycompany.org" id="b6dcd86388ad33df" version="1.0" >
  29.  
  30. R:
  31. <stream:features xmlns:stream="http://etherx.jabber.org/streams">
  32.  <compression xmlns="http://jabber.org/features/compress">
  33.     <method>zlib</method>
  34.  </compression>
  35.  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  36.     <mechanism>PLAIN</mechanism>
  37.  </mechanisms>
  38. </stream:features>
  39.  
  40. S:
  41. <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">MREmADH8Njg3Mjgy</auth>
  42.  
  43. R:
  44. <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  45.  <not-authorized />
  46. </failure>
Avatar
Alex 2016-11-23, 15:29 #2
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Quote by SimonBrinkmann:
I have an issue where 2 clients register to the same Cisco IM & Presence from the same process/application. The first client1 is required starttls and offered two Sasl-Mechanisms but  client2 registering is NOT required to send starttls and is only offered PLAIN as sasl mechanism.

If I switch the clients so that client2 is registering first I get the that client2 has starttls required and offered 2 sasl-mechanisms and client1 only gets 1 sasl-mechanism.

Any ideas what might cause this behavior?

The response is coming from the server. The client is always sending exactly the same open stream. I guess only CISCO could tell you why they send different stream features.

Or are you calling xmppClient.Open() twice on the same XmppClient instance? This of course would not work.


Quote by SimonBrinkmann:
I also remark that the client2 is not reusing the stream (different stream id's)

You cannot reuse a stream. If you create 2 instances of XmppClient for some reason in your application then you of course end up with 2 concurrent XMPP streams.
This post was edited on 2016-11-23, 18:46 by Alex.
Avatar
SimonBrinkmann 2016-11-25, 12:32 #3
Member since Sep 2013 · 7 posts · Location: Norway
Group memberships: Members
Show profile · Link to this post
Quote by Alex on 2016-11-23, 15:29:
1479911358

Not calling open() twice.


Quote by Alex on 2016-11-23, 15:29:
1479911358

What I meant to say was: There is a difference in how the streams are restartet. Client1 keeps the stream id for each restart whereas client2 get a new streamid for each restart.

Does that mean anything or is it up to the server to decide?

Thanks.
Avatar
Alex 2016-11-25, 12:43 #4
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
the stream Id gets provided by the server, the client cannot affect it.
When establishing a session to a XMPP server there are multiple stream restarts in the XMPP protocol. And a server should assign new stream ids on the stream restarts, so that absolutely fine when you see the Id changing after a new stream header was sent from the client.

Alex
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:

Forum: MatriX and XmppDotNet RSS