Now that I have my connection manager up and connected to my Wildfire server I can connect Spark clients just fine but all other clients (Exodus, PSI, Pandion) connect then hang while ‘‘authenticating’’. If I configure these clients to connect to the CM server by name and use SSL (port 5223) they are able to connect via the CM. These other clients are also able to connect directly to the Wildfire server by name using TLS (port 5222). They just can’'t do TLS directly to the CM host, even by name with the specific port (ruling out DNS issues).
While I have work arounds and I can obviously deploy Spark as my default client it makes me nervous that other clients won’'t work out of the box with auto-configuration. Should I expect clients other than Spark to work via the CM with TLS?
I’'ve had Trillian Pro 3 working with TLS through a connection manager.
Have you made sure the SSL certificates you have installed for the CM correspond to the encryption methods supported by the client?
Where are you trying to identify TLS use through?
The session list currently doesn’'t show TLS/SSL properly.
I’'ve been identifying TLS use by looking at the output of netstat on the Connection Manager host to verify the clients are connected via port 5222. After re-doing my certificates I am still seeing the same behavior, only Spark can connect and authenticate through the Connection Manger.
Currently I’'m testing with five different clients just to see the different error messages they might give me but all five behave the same. LinQ actually provides the most feedback in terms of what is really happening. When I try it I can see it go through these phases…
At which point it just sits there and spins. Other clients like PSI just say ‘‘connecting’’ or ‘‘one moment please’’ forever. On the back-end the Wildfire server doesn’‘t show client sessions for these clients however on the ‘‘Connection Managers’’ page the ‘‘Client Session’’ count does reflect that these clients are connected to the Connection Manager. Bear in mind all these clients will work fine if I point them directly to the back-end Wildfire server by hostname. Unfortunately in my environment I’'m going to have ~4,000 concurrent connections from day one so I need to have everyone connecting via the Connection Managers to ensure the service will scale.
I have found that each time I attempt to connect with a client other than Spark via the Connection Manager, I get the following in stderror.log on the Wildfire server itself:
Exception in thread “pool-11-thread-3” java.lang.UnsupportedOperationException
at org.jivesoftware.wildfire.ldap.LdapAuthProvider.getPassword(LdapAuthProvider.ja va:120)
at org.jivesoftware.wildfire.auth.AuthFactory.getPassword(AuthFactory.java:111)
at org.jivesoftware.wildfire.net.XMPPCallbackHandler.handle(XMPPCallbackHandler.ja va:66)
at com.sun.security.sasl.digest.DigestMD5Server.validateClientResponse(Unknown Source)
at com.sun.security.sasl.digest.DigestMD5Server.evaluateResponse(Unknown Source)
at org.jivesoftware.wildfire.net.SASLAuthentication.handle(SASLAuthentication.java :248)
at org.jivesoftware.wildfire.multiplex.MultiplexerPacketHandler.route(MultiplexerP acketHandler.java:168)
at org.jivesoftware.wildfire.net.ConnectionMultiplexerSocketReader$2.run(Connectio nMultiplexerSocketReader.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Again these same clients can authenticate directly to the Wildfire server if I specify host/port. They can also connect via the Connection Manager if I configure them to use SSL. I am using LDAP to authenticate users. I’‘m not sure if this is a show stopper for me but it’‘d be way neater to push Wildfire as my IM solution if most clients simply connected out of the box in automatic mode, which for all of them seems to be user’'s domain srv record for xmpp-client and TLS.
Message was edited by: St0nkingByte
Hey St0nkingByte,
Good catch. Some authentication mechanisms require to have access to the user password such as when using Digest-MD5. For some reason your clients are using a different SASL mechanism when connecting directly to Wildfire or through CMs. You can open a traffic window in the client to compare how the client is authenticating with the server in each case.
Anyway, I think that the server should not be offering SASL mechanisms that require a user password when using LDAP (or any back end that does not allow to retrieve users’’ passwords) so that clients don’'t have this problems. Meanwhile, you can set the property sasl.mechs in the XML file with the SASL mechanisms that you want to offer. Restart the server after setting this property.
Regards,
– Gato
I had the same problem today when setting up a CM for the first time for testing.
I was able to get it to connect properly by setting (in manager.xml on the CM machine):
What I don’'t know, however, is does this disable SSL between the CM and the WildFire server?
Also, I’‘m somewhat disconcerted that when viewing the “Session” panel on the WildFire admin page, clients who have connected via the CM report the IP of the CM, not the actual client’'s IP. Is there any way to get it to pass that information along to WildFire?
Hey MMorey,
When you disable certificate validation you are just indicating CM to
trust any certificate presented by Wildfire. Certificates are used for
validating the identity of the other peer so what you are saying is "I
trust this guy". As you can imagine this is not ideal for production
environments and the security team may not accept such configuration.
Anyway, the connection between the CM and Wildfire will still be secure.
Regarding the actual client’'s IP address, that feature is not available
right now and is planned for the next Connection Manager release. We
still not have a release date for the next release of Connection
Managers but it may happen in 1 or 2 months from now.
Thanks,
– Gato
Cool, thanks for your prompt reply!
Just to make sure I get this straight: The config I quoted should not affect the encryption of data flowing from clients through the CM, only traffic flowing from CM <-> WildFire.
I was originally planning to have our WildFire server on the backend with only connection managers facing the outside world, so this should not be a security issue, correct?
Getting a bit off-topic here, but now that I think about such a layout a bit more, would this affect the functionality of the WF server itself (i.e. does port 7777 on the WF machine need to be facing the outside world in order to be able to proxy file transfers successfully, or will the CM handle this functionality as well? I suppose if the WildFire backend must be publically available, we could restrict via firewall the CM ports to only allow traffic to/from our known CM’'s.
Also I was wondering if there is any downside to load-balancing the Wildfire server’‘s port 5222 with a few connection manager’'s port 5222, making the WildFire server handle a share of the connections directly the same way a group of connection managers would?
Sorry, that was quite a mouthful
Regards,
M
Hey M,
MMorey wrote:
Cool, thanks for your prompt reply!
Just to make sure I get this straight: The config I quoted should not affect the encryption of data flowing from clients through the CM, only traffic flowing from CM ↔ WildFire.
With your setting you are instructing the CM to trust the certificate presented by Wildfire. Anyway, traffic between the CM and Wildfire will still be encrypted. In other words, your setting does not affect the traffic flow. Clients can still use secure or unsecure connections to the CM.
I was originally planning to have our WildFire server on the backend with only connection managers facing the outside world, so this should not be a security issue, correct?
As long as you are sure that CMs will always connect to your server then there is no security problem. A problem may happen if someone hacks your DNS server and changes the domain of your server to resolve to some other address. In that case your CM will connect not to your server but to something else.
Getting a bit off-topic here, but now that I think about such a layout a bit more, would this affect the functionality of the WF server itself (i.e. does port 7777 on the WF machine need to be facing the outside world in order to be able to proxy file transfers successfully, or will the CM handle this functionality as well? I suppose if the WildFire backend must be publically available, we could restrict via firewall the CM ports to only allow traffic to/from our known CM’'s.
Connection Managers only handle client-2-server traffic (ports 5222 and 5223 by default). That means that server-2-server and file transfer through a proxy will still need to go directly to your Wildfire server. Therefore, ports 5269 and 7777 (and 9090 and 9091) need to go directly to your server.
Also I was wondering if there is any downside to load-balancing the Wildfire server’‘s port 5222 with a few connection manager’'s port 5222, making the WildFire server handle a share of the connections directly the same way a group of connection managers would?
Nope. There is no problem. When using CMs Wildfire is still able to handle direct connections from clients.
Sorry, that was quite a mouthful
No problem.
Regards,
– Gato
OK my problem is solved.
I changed /conf/wildfire.xml on my Wildfire server (not the Connection Manager) to include the following section:
<sasl>
<mechs>PLAIN</mechs>
</sasl>
Now all clients connecting via the Connection Manager authenticate just fine. Thanks for the help!
Hey St0nkingByte,
I’'m now testing Wildfire + LDAP and the only SASL mechanisms that are being offered are PLAIN and ANONYMOUS as shown below:
Could you open a traffic window and check that Wildfire was in fact offering DIGEST-MD5? Clients should only try to use SASL mechanisms that were offered by the server. Which client were you using?
Regards,
– Gato