BUG FIXED YET? - GAIM/Jive SSL Connect Failures

Hi All,

Has anyone been successful yet in connecting the GAIM client to Jive Server over SSL? I haven’'t heard anything about this in quite a while. I love your server, but I am this close to attempting a full blown JabberD install because I cannot get the client to connect over SSL.

Thank you,

Ken

Ken,

Unfortunately, there’‘s no progress on this issue yet. There’‘s something that’‘s incompatible between Jive Messenger and the GAIM library. One thing you could try – if you were able to find any other Java XMPP servers that work with GAIM, that would tell us that it’'s a problem in the Jive Messenger code instead of a Java issue.

Regards,

Matt

I thought you had already tracked the problem down to the mozilla-nss library. RedHat just updated their gaim package from v1.1.4 to 1.2.1and in doing so they switched to mozilla-nss and thus their gaim client now fails to connect.

I also thought it was the Mozilla-NSS library. Unfortunately, I don’'t have much more info on this. Neither the GAIM or JIVE camps seem to accept this as problem with their product. However, the more I have read into it, it seems more on the JIVE side. Other clients besides GAIM appear to have similar issues.

I can’'t hold off any longer waiting for the next release which may or may not have a fix so am moving to building a JabberD 2 Server with MySQL and Bandersnatch.

I am eager to see the fixed version though, or perhaps the upcoming TLS version of JIVE will eliminate the issue. Hopefully the developers are able to locate the problem and resolve the issue.

To be fair, the guys a JIVE did make contact with the guys at GAIM to try and resolve, but it didn’'t go anywhere.

Well if the problem is incompatibility with Mozilla-NSS, and vendors like RedHat are moving to using Mozilla-NSS, then I would think it should be a priority to fix the problem. Otherwise we are going to run out of IM clients that work.

Of course it is trivial to patch gaim to use gnutls (it is a configure option), but my client likes to pay for support and use supported software. Getting a great system like Jive in the door is hard enough, but then to say I have to patch all our IM clients… well that dog doesn’'t hunt.

So what is the deal? Why does the gaim author (or RedHat?) say:

  1. gnutls is buggy so use mozilla-nss on all distributions

in the RedHat rpm spec file?

Hmm, don’'t know. But JM is OpenSource. So if it is a priority, you are very welcome to provide a patch. I guess the devs would be realy glad about it.

OpenSource doesn’‘t make every customer responsible for patching the code to make it work. Ignoring serious bugs because someone else can fix it is a bad practice. That is what leads to orphaned projects. If the existing dev community doesn’'t think this is problem, or simply lacks the expertise to fix it, then that is significant issue for any customer looking to adopt the package.

It isn’'t necessarily a priority to me to contribute to the effort to get it fixed. I have the option to use a different package, after all. Or I can grin and bear it, and keep patching my clients.

In this case, I like what I see in Jive to make me want, really want, to find the time to help. I’‘m just hoping there is someone out there who has played with the two ssl libraries enough to have a much much better chance of finding and fixing the problem. Debugging ssl connections can’‘t be very fun. But if anyone has a suggestion on where to start, I’'ll take a look.

Hey guys,

We’‘re eager to solve this problem as well. If anyone is interested in helping us fix the issue, there’'s a key question we need to get answered:

Is this a Java SSL issue or something we’'re doing in Jive Messenger?

The easiest way to test this would be to try other Java XMPP servers with clients that break under JM. Specifically:

Once we get that question answered, we’'ll know what avenue to pursue for a fix. Anybody willing to help out by doing some testing?

Thanks,

Matt

I just installed OpenIM and tried a connection (latest GAIM, with SSL).

Out of the box I get the following:

(openim.IMConnectionHandler): Connection from /127.0.0.1:7128

(openim.IMConnectionHandler): Algorithm missing:

javax.net.ssl.SSLException: Algorithm missing:

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.changeReadCiphers(Unknown

Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un

known Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source

)

at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)

at java.io.DataOutputStream.write(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(Unknown Source)

rethrown from

java.security.NoSuchAlgorithmException: Cannot find any provider supporting RC4

at javax.crypto.Cipher.getInstance(DashoA12275)

at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(Unknown Source)

at com.sun.net.ssl.internal.ssl.CipherBox.(Unknown Source)

at com.sun.net.ssl.internal.ssl.CipherBox.newCipherBox(Unknown Source)

at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.newCipher(Unknown

Source)

at com.sun.net.ssl.internal.ssl.Handshaker.newReadCipher(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.changeReadCiphers(Unknown

Source)

(openim.IMConnectionHandler): Release session 1118302422077

(openim.IMClientSession): Session dispose failed (stage2): Connection

has been shutdown: javax.net.ssl.SSLException: Algorithm missing:

(openim.defaultconnectionmanager): Error handling connection

java.io.IOException: Algorithm missing:

at net.java.dev.openim.IMConnectionHandlerImpl.handleConnection(IMConnec

tionHandlerImpl.java:114)

at org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(

Connection.java:224)

at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(Executabl

eRunnable.java:90)

at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:1

So it complains about a missing “RC4” crypto provider… Could it be related to the Jive problem? Can I test anything else? (The documentation for OpenIM lacks a little bit…)

Regards,

Ben

I tried tigase as it also uses java 1.5… I recieved a bit different error when trying to log in w/ old ssl and gaim…

WARNING: Protocol execution exception.

java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: no cipher suites in common

at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)

at java.util.concurrent.FutureTask.get(FutureTask.java:80)

at tigase.server.ClientThread$ResultsListener.run(ClientThread.java:178)

Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common

at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Handshaker.java:994)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:4 59)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:10 54)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1026)

at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:411)

at tigase.services.TLSWrapper.wrap(TLSWrapper.java:129)

at tigase.services.AbstractServerService.sslWriteData(AbstractServerService.java:3 41)

at tigase.services.AbstractServerService.writeData(AbstractServerService.java:368)

at tigase.services.AbstractServerService.decodeData(AbstractServerService.java:242 )

at tigase.services.AbstractServerService.readData(AbstractServerService.java:278)

at tigase.services.AbstractServerService.processSocketData(AbstractServerService.j ava:400)

at tigase.services.AbstractServerService.call(AbstractServerService.java:193)

at tigase.services.AbstractServerService.call(AbstractServerService.java:60)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)

at java.util.concurrent.FutureTask.run(FutureTask.java:123)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common

at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)

at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1352)

at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:176)

at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:164)

at com.sun.net.ssl.internal.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshake r.java:639)

at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java :450)

at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.j ava:178)

at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)

at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Handshaker.java:437)

at java.security.AccessController.doPrivileged(Native Method)

at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Handshaker.java:932)

at tigase.services.TLSWrapper.doTasks(TLSWrapper.java:164)

at tigase.services.TLSWrapper.unwrap(TLSWrapper.java:121)

at tigase.services.AbstractServerService.decodeData(AbstractServerService.java:235 )

… 9 more

Thanks guys, that helps quite a bit. I have something I’'d like to try today, which is to bundle in a different security provider (bouncycastle) than the standard one.

I did a lot of google searching on this issue last night and couldn’‘t find anything. If there’'s really a compatability issue between Java and the moz ssl libs, you would think that would be affecting tons of people.

Regards,

Matt

Hmm, my first test with bouncycastle didn’‘t do anything to fix the problem. I’'ll try again a bit later today if I get the chance.

-Matt

Ok, my next plea for help… Can anyone let me know which version of NSS GAIM uses? Is 3.10 being used yet?

Thanks,

Matt

It seems it uses version 3.9

In the Windows Gaim buildup page: http://gaim.sourceforge.net/win32/build.php

the NSS link points to a 3.9 zip file: Network Security Services (NSS) ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_9_RTM/WIN954.0 _OPT.OBJ/nss-3.9.zip

I hope this helps!

Would anyone be interested in testing with NSS 3.10 to see if that works? Here’'s what I tried tonight:

  • Created RSA key in keystore to see if that worked (default key is DSA).

  • Tried the 1.4 JCE impl in JDK 1.5 based on a somewhat random forum post on java.sun.com.

Still no dice so I’'m not sure what the next step is.

-Matt

Hrrrmmm… I tried building the linux version of gaim against nspr 4.4.1 and nss 3.10 but it doesn’'t seem to want to compile for me…

Gaim compiles fine against whever libs ship w/ moz 1.7.8, but that doesn’‘t seem to be 3.10. (And it also doesn’'t fix our ssl problem)

Used linux builds of nss/nspr from

ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/

ftp://ftp.mozilla.org/pub/mozilla.org/nss/releases/

Ok, I might have something. From an FAQ I found:


Socket Disconnected after Sending ClientHello Message

Problem: A socket attempts to connect, sends a ClientHello message, and is immediately disconnected.

Cause: Some SSL/TLS servers will disconnect if a ClientHello message is received in a format it doesn’‘t understand or with a protocol version number that it doesn’'t support.

Solution: Try adjusting the protocols in SSLSocket.setEnabledProtocols. For example, some older server implementations speak only SSLv3 and do not understand TLS. Ideally, these implementations should negotiate to SSLv3, but some simply hangup. For backwards compatibility, some server implementations (such as SunJSSE) send SSLv3/TLS ClientHellos encapsulated in a SSLv2 ClientHello packet. Some servers do not accept this format, in these cases use setEnabledProtocols to disable the sending of encapsulated SSLv2 ClientHellos.


That problem description is exactly what I’‘m seeing with Trillian. I’‘m going to experiment with this tonight to see if it’'s a fix and will post progress.

-Matt

Yay!! I found the fix for GAIM (at least with the Windows GAIM client I’‘m testing with). The default self-signed cert we ship with is for DSA but not RSA connections. Apparently GAIM SSL doesn’‘t support DSA and requires RSA. The fix is to add another self-signed cert to the keystore that uses the RSA algorithm. I’'ve attached a new keystore that includes both RSA and DSA certs. This will be included in the next release.

Alternatively, you can add a self-signed RSA cert using the following command:

keytool -genkey -alias rsa -keystore keystore -keyalg rsa

The (somewhat) bad news is that this fix doesn’‘t solve the Trillian SSL problems. However, Rachel Blackman (author of the XMPP plugin in Trillian) let me know that she’‘s finally been able to fix the problem by using a newer version of Open SSL and the latest Java patch release. There isn’‘t a release date on the fixed version of Trillian yet, but I’'ll post again as soon as I have more info.

Regards,

Matt

Ok, one final update. See the attached screenshot of both GAIM and Trillian connected through SSL to my local Jive Messenger instance (Trillian working through a beta version of the plugin).

-Matt

(first post)

good catch, I have an installed instance of Jive Messenger (2.1.4) that I can confirm using an RSA signed key will allow gaim users to connect.

here’‘s the keytool (from Sun’'s SDK) commands to create your own certificate:

  • keytool -genkey -keystore /path/to/store.jks -alias rsa-cert -keyalg RSA

if you are self-signing:

  • keytool -selfcert -keystore /path/to/store.jks -alias rsa-cert -validity 1095

if you are getting your cert signed by a certificate authority:

  • keytool -certreq -keystore /path/to/store.jks -alias rsa-cert -file /path/to/rsa-cert.csr

(submit your CSR, when you receive the reply)

  • keytool -import -keystore /path/to/store.jks -alias certificate-authority -file /path/to/certificate-authority.cert

  • keytool -import -keystore /path/to/store.jks -alias rsa-cert -file /path/to/ca-reply.cert

Thanks!