Spark 2.0 -> Wildfire (Alt Port SSL Breakage?)

hello,

we’'re running wildfire 2.6.2 using alt port ssl; spark 1.1.4 had been working fine in this scenario. Spark 2.0 will not. It reports a bad user name and password. Server side, the error logs report:

2006.09.08 09:30:47 org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:161) Connection closed before session established

134d4a1[SSL_NULL_WITH_NULL_NULL: Socket[addr=/128.135.x.y,port=65506,localport=5223]]

where 128.135.x.y is the IP of the workstation trying to connect. Any news or other reports of this?

This sounds similar to the issue I am having in this thread:

http://www.jivesoftware.org/community/thread.jspa?threadID=21757&tstart=0

Regards,

Ken

We are having the same issue.

Using Wildfire 2.5.1.

We set our clients to communicate using XMPP port 443 and specify the USE OLD SSL PORT method.

2006.09.09 01:18:16 org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:161) Connection closed before session$

5c54be[SSL_NULL_WITH_NULL_NULL: Socket[addr=/XXX.XXX.XXX.XXX,port=1611,localport=443]]

2006.09.09 01:18:57 org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:161) Connection closed before session$

16fb664[TLS_DHE_RSA_WITH_AES_128_CBC_SHA: Socket[addr=/XXX.XXX.XXX.XXX,port=1623,localport=443]]

2006.09.09 01:18:57 org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:161) Connection closed before session$

1ab4a9[TLS_DHE_RSA_WITH_AES_128_CBC_SHA: Socket[addr=/XXX.XXX.XXX.XXX,port=1624,localport=443]]

Hi All,

Are you all trying to connect to a specified domain or an ip address?

Thanks,

Derek

Hi Derek,

Domain, in this case, im.uchicago.edu.

Thanks,

Andrew

domain in our case as well.

Hey guys,

Basically, we’‘re not convinced that Spark should continue to support the old SSL connection option. It’‘s not XMPP compliant, and Wildfire and other servers have supported TLS connections over 5222 for a long time. Is there a reason that you can’'t use TLS connections instead?

Spark 2.0.0 did still include the old-style SSL as a connection preference, which was a mistake. We’'ll get that fixed.

Regards,

Matt

hey,

the reason for us is that we’‘ve been using jabber internally since 2002, prior to STARTTLS being an option; in Wildfired 2.6.2, some clients broke if you allowed both options at once (Gaim, Pandion (offshoot of http://www.jivesoftware.org/issues/browse/JM-749 ?). Correspondingly, we’'ve deployed Spark in the only manner that /could/ work while our server supports a range of clients.

Because of this, we’‘re looking at moving to 3.0.1 this week (mass deployment (10,000 pre-configured copies) of Spark is next week, on an already burned CD with 1.1.4, which will immediately prompt the user to upgrade and then unconfigure itself); hopefully 3.0.1 fixes the problem for our existing clients our we’'re going to have a problem.

the reason for us is that we’‘ve been using jabber internally since 2002, prior to STARTTLS being an option; in Wildfired 2.6.2, some clients broke if you allowed both options at once (Gaim, Pandion (offshoot of http://www.jivesoftware.org/issues/browse/JM-749 ?). Correspondingly, we’'ve deployed Spark in the only manner that /could/ work while our server supports a range of clients.

Thanks, that makese sense. Hopefully JM-749 does the trick and it won’‘t be an issue. If that’‘s the case, there shouldn’'t need to be a reason to support old SSL in Spark 2.x, right? BTW, bummer that you missed the window with the new Spark release.

Regards,

Matt

Matt,

Assuming everything works, that fixes half of our problem; we’‘ll still need to find a way to re-configure the 10,000 clients we’‘re deploying in … 5 days. We have some mechanisms to /help/ this, but as a University we don’‘t control most of our user’'s desktop.

For us (and I’‘d assume most in a similar situation), we need a LOT more notice if you are going to make a major change like drop support for a common connection method, or blow away user configuration, at least if we’'re going to distribute Spark to thousands of users.

hello,

I have updated our server to 3.0.1, serving both starttls and alt-port ssl and am testing the new 2.0.1 version of Spark.

I can only connect to our server if I both add a server to the server field on the entry screen and input settings for the hostname field in the advanced settings. There is nothing unique about the information I’'m inputing the second time. This does not seem like the intended behavior … is it?

FWIW,

it also works if I input the IP address into my server field (w\o additional hostname information). We did discover that our PTR record for our IM server’'s IP points back to an CNAME record instead of the appropriate A record. Does the Spark try any reverse DNS lookups or comparable?

Hey Matt,

Luckily I was only testing the client on a few machines. I am sure this EOL was mentioned somewhere, however, the autoupgrade not alerting the user to it. That isn’'t a good thing, maybe some type of alert could be added to the install program? Or the update Notification?

I plan on upgrading my configuration, both with WildFire’'s latest release and the Spark client down the road. It just slows deployment of Spark. We now need to stay with Pandion.

Like other users we have a small IT department and have been running the server in this configuration long term. A quick migration to the new server isn’'t always easy to do on the fly. I am just happy I never deployed the pre-2.0 Spark to users. We would have been SOL.

Best Regards,

Ken

Sounds very strange. Any chance that you have a DNS SRV entry that’'s pointing to the wrong place? Spark will look for a DNS SRV record for the XMPP server given the server name. So, if I enter “jivesoftware.com” on the login screen, but the SRV record says that the server lives at “xmpp.jivesoftware.com”, then it will make the actual connection there. Entering the server name in the advanced setting short circuits that logic so that it goes exactly where you tell it.

Is your server on a public network? I could test all of this pretty easily if so.

Regards,

Matt

we’'re public, im.uchicago.edu, please, give it a shot!

Shortly after Andrew replied, we discovered what may likely be the problem:

host -t srv xmpp-client.tcp.im.uchicago.edu

xmpp-client.tcp.im.uchicago.edu has SRV record 5 0 5223 im.uchicago.edu.

Note that this points to port 5223 instead of 5222, as our server had port 5222 disabled until recently to prevent down-level clients from exposing passwords over a plaintext channel. We’'ll have the record updated and see if that helps.

For any others in this situation, the dns srv changes fixed the remaining problem; through the upgrade on our end and the settings-migration behavior of 2.0.1 (nice timely release, thanks!), we’'re good to go.

-Ah