Description of problem: The Gajim IM client cannot connect to Jabber servers running Openfire. Version-Release number of selected component (if applicable): gajim-0.12.5-1.fc12.x86_64 openssl-1.0.0-0.10.beta3.fc12.x86_64 python-2.6.2-2.fc12.x86_64 java-1.6.0-openjdk-1.6.0.0-1.2.b09.el5 openfire-3.6.4-1 How reproducible: Always Steps to Reproduce: 1. Connect to openfire XMPP server Actual results: Application hangs Additional info: Gajim worked properly under F11. To try to narrow the problem down I copied libcrypto and libssl from F11 into /home/gordon/openssl098k/. I created symlinks from libcrypto.so.0.9.8k to libcrypto.so.10, and libssl.so.0.9.8k to libssl.so.10. I know that's the wrong thing to do, but it took less time and effort than rebuilding python against the older openssl. When I start gajim with those libraries: LD_LIBRARY_PATH=/home/gordon/openssl098k/ gajim I'm able to connect to openfire servers. Using the standard openssl on F12, the application hangs. With the working openssl from F11, the client starts the TLS handshake with 145 bytes. With the openssl from F12, the client starts the TLS handshake with 111 bytes. This bug doesn't affect Google's Jabber server. Gajim connects to it without problems. It also doesn't affect the Empathy client. Empathy can connect to both openfire and Google's Jabber server without hanging. It's harder for me to get more info on Empathy, since it uses separate processes for Jabber communication.
Are you able to connect to the server manually with the openssl s_client command and get some response from the established TLS connection?
No, I'm not. s_client will hang in exactly the same spot. I'll attach the strace output, in case that's helpful.
Created attachment 367752 [details] strace output strace -s 256 -o ssl.trace.txt openssl s_client -connect phantom.dragonsdawn.net:5223
I probably should have figured out that Empathy uses GnuTLS sooner. That's why it's able to connect to those servers.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Here is the upstream tracker entry. http://rt.openssl.org/index.html?q=2102 Unfortunately the more I am looking at this the more I am afraid that the openfire servers just need fixing or the gajim has to use SSL_OP_NO_TICKET and SSL_OP_ALL flags when establishing the connection. By the way: openssl s_client -no_ticket -bugs -connect phantom.dragonsdawn.net:5223 works.
Is the RT data available elsewhere without a login? As far as I know, openfire uses the standard SSL support in the JVM. In this case, I'm seeing the problem with java-1.6.0-openjdk-1.6.0.0-1.2.b09.el5. I don't know of another SSL-enabled java service that I can test, but I'd be willing to bet that all interoperability between openssl-1.0beta and OpenJDK servers are affected. Would it be appropriate to open a bug for openjdk under RHEL regarding this problem?
Opening a bug against openjdk might be a good idea as the behaviour where it does not send a reply to a valid TLS client hello is clearly buggy. You can access the RT by using user guest password guest.
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=e318b005a6a9260f018bac29c7ac?bug_id=6728126 Here is the Java bug.
Hi, the last version of Openfire (3.6.4) is bundled with java version "1.6.0_03". This problem is reproduced with Gajim, PSI, Kopete
Any updates on this issue? We have Gajim users who traditionally use it to connect to our XMPP (Openfire) server, but cannot now since upgrading to Fedora 12. Thanks.
It'd be nice if there were some way to disable session cookies for F12 without modifying the application, but hopefully the bug in Java can be fixed. That's filed as Red Hat bug 540384, for those that want to follow it.
I do not see much chance this would be fixed on openssl upstream and we do not want to diverge from upstream on this. Note that the openfire servers will need update sooner or later to fix CVE-2009-3555 which will require a fix for proper TLS extension support anyway.
Using SUN JDK 1.6.0_17 on openfire server fixes this issue.
Tomas, presumably you mean that their Java installation will need to be updated, is that correct? OpenJDK on RHEL was already updated for that CVE, as I understand it, but the problem is still present there.
I've commented on an open issue for Openfire regarding updating the bundled JRE: http://www.igniterealtime.org/issues/browse/OF-88 I bet one could easily switch Openfire server to use the local OS's installed JRE, instead of the bundled version, as an interim fix.
Gordon, yes. The server's java (possibly the bundled one with Openfire) needs to be updated.