https://bugzilla.novell.com/show_bug.cgi?id=832347 https://bugzilla.novell.com/show_bug.cgi?id=832347#c0 Summary: Pidgin with ssl-gnutls.so hangs with Tigase XMPP server (Java) Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jimc@math.ucla.edu QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Versions: pidgin-2.10.7-4.4.1.x86_64 empathy-3.6.3-2.1.3.x86_64 libgnutls28-3.0.28-1.1.1.x86_64 Tigase-5.1.5 from http://www.tigase.org/ (written in Java) java-1_7_0-openjdk-1.7.0.6-8.14.5.x86_64 java-1_7_0-openjdk-devel-1.7.0.6-8.14.5.x86_64 2 Android clients and 4 Linux boxes with the above version of Pidgin and libgnutls28 can connect to Tigase (on one of those boxes) with TLS and function. 2 similar Linux boxes (one x86_64 and one i586) hang while connecting. They always hang, with many repetitions and no matter which user runs Pidgin. Gnome's Empathy hangs similarly, even from the machines from which Pidgin can connect. Tcpdump on a successful machine shows the client sending starttls, the server sends proceed, the client sends a packet of about 140 bytes containing the XMPP domain (whose cert it wants to see), the server sends the certificate chain, and the connection proceeds. Tcpdump on a failing machine shows starttls and proceed, whereupon the client sends a binary packet larger than 256 bytes (no domain) which the server acks, and both peers just sit there. Tigase prints nothing in its logs. After investigation I noticed that Empathy uses libgnutls28, whereas Pidgin (libpurple) has plugins for both GnuTLS and NSS. I sabotaged /usr/lib64/purple-2/ssl-gnutls.so by setting its mode to 000, forcing Pidgin to use ssl-nss.so instead. It actually does so with no error messages and connects to the server and functions, where formerly it would hang. Various forum postings suggest that the client and server botch the negotiation of which TLS version to use, the client does TLSv1, and the server fails to recognize it. They suggest a variety of maneuvers to make TLSv1 impossible, like suppressing required ciphers, which seem to help the reporting users. A wide variety of server and client software is affected. Usually a working system starts failing after a version upgrade on the client or on the server. Frequently it's reported that some clients or servers fail and some don't. A warning was posted that openssl s_client botches the starttls procedure with some but not all XMPP servers; my experience is that it always hangs when connecting to Tigase. I was unable to discover: * Which plugin Pidgin actually used (strace shows all being opened). * Why it works on some hosts and not others. * The "right" way to influence which TLS plugin libpurple will use. strace doesn't show config files being searched for but not found. * How to influence GnuTLS's choice of the TLS version, or ciphers. * The same choices for Java (Tigase). I would not be surprised to find that the GnuTLS devs are saying "it's a server bug" while the server people are saying "GnuTLS is horked". I hope that someone with a whole lot more expertise than me could discover what the bug really is and rub some dev's nose in it. In any case, it's really discouraging for the end user to find excellent server and client software put out of action by an infrastructure bug that doesn't even appear consistently. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.