Bug 533234
| Summary: | Compatibility regression in openssl | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gordon Messmer <gordon.messmer> | ||||
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | jwest, llg, tmraz | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-01-13 19:41:02 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Gordon Messmer
2009-11-05 18:22:04 UTC
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. |