Mailinglist Archive: opensuse-bugs (3714 mails)

< Previous Next >
[Bug 832347] New: Pidgin with ssl-gnutls.so hangs with Tigase XMPP server (Java)
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 31 Jul 2013 03:48:40 +0000
  • Message-id: <bug-832347-21960@http.bugzilla.novell.com/>

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@xxxxxxxxxxxxxxxxxxxxxx
ReportedBy: jimc@xxxxxxxxxxxxx
QAContact: qa-bugs@xxxxxxx
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.

< Previous Next >
This Thread
  • No further messages