By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2669

Summary:	Kopete troubles with TLS
Product:	TDE	Reporter:	Kristopher <gamrat.kristopher>
Component:	tdenetwork	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bugwatch, gamrat.kristopher, slavek.banko
Priority:	P5
Version:	R14.0.x [Trinity]
Hardware:	Other
OS:	Linux
See Also:	http://bugs.pearsoncomputing.net/show_bug.cgi?id=698
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Bug Depends on:
Bug Blocks:	2575
Attachments:	Error message Kopete displays Server settings

Description Kristopher 2016-07-05 12:56:57 CDT

NOTE: This is for R14.0.3 on Debian Jessie and pertains to the XMPP (Jabber) protocol.

Kopete's TLS implementation seems to work only on 5223 and seems to refuse working on port 5222. This is an issue because some services use port 5222 only and require an encrypted connection.

As an example, connecting to dukgo.com with TLS enabled using port 5223 takes a full minute of trying to connect before producing the follow error:


There was a connection error: Operation is not supported.


Trying to use port 5222 produces the following error without delay:


There was a Transport Layer Security (TLS) error: Failed to establish a secure connection.


Using Psi+ to establish a TLS-encrypted connection on port 5222 (*not* 5223) works perfectly.

Comment 1 Kristopher 2016-07-31 12:40:16 CDT

Adding 'See Also' for bug 698. It mentions there that StarTLS is now part of the Jabber specification. Resolving bug 698 may resolve this bug.

Comment 2 Slávek Banko 2016-10-15 19:17:15 CDT

Within bug 698 was resolved primarily StartTLS problem.
Therefore, now, this bug report can also be closed.

Comment 3 Kristopher 2016-11-10 21:54:18 CST

I am reopening this because it is not fixed on R14.0.4, which (if I understand the release notes correctly) should include the fixes applied in bug 698. I did do a full reboot after upgrading TDE to ensure it would be fully reloaded (including the login manager and any libs it needs that may have been upgraded).

I removed my jabber accounts from Kopete then re-added my main account only. As usual, it defaulted to port 5223 for an encrypted connection, then complained that it could not establish an encrypted connection. I then overrode the server information to force the use of port 5222 (which should be the default anyway), and I received the same complaint from Kopete.

The server I am connecting to does support (and require) a TLS-encrypted connection over port 5222.

I will attach screenshots.

Comment 4 Kristopher 2016-11-10 21:55:28 CST

Created attachment 2738 [details]
Error message Kopete displays

This message displays regardless of whether I use force the use of 5222 or allow Kopete to use port 5223.

Comment 5 Kristopher 2016-11-10 21:56:51 CST

Created attachment 2739 [details]
Server settings

This shows the server settings I am using. The settings are correct. I also have the correct JID on the "Basic Setup" tab, and I have tried re-typing the password several times to no avail.

Comment 6 Kristopher 2016-11-10 21:58:58 CST

I should also note that my jabber.org account no longer works. On R14.0.3, my jabber.org account would connect over TLS using port 5223, but now it displays the same error as in the screenshot for my jabber.org account regardless of whether I use port 5223 or port 5222.

Comment 7 Slávek Banko 2016-11-11 18:07:20 CST

I believe that you've got two problems in your configuration:

1) Switch Use protocol encryption (SSL) forces to use old way for encryption == used with the old XMPP protocol on port 5223. If you want to use a new XMPP protocol with StartTLS (on standard port 5222), you have to leave this switch turned off.

2) Switch Override default server information, when it is on, this also switches to using the old XMPP protocol == preventing the use StartTLS. If you want to use a new XMPP protocol with StartTLS, you have to leave also this switch turned off.

In short, both of these switches negate the use of the new XMPP protocol with StartTLS. Please try both mentioned switches to turn off.

Comment 8 Kristopher 2016-11-11 20:12:46 CST

Hmm, before neither server would work with or without those enabled, but now dukgo.com mysteriously started working with them turned off. My jabber.org account still won't work regardless of what combination of options I choose, though this may be bug 2726 causing it to lag out before it can negotiate an encrypted connection (I can't say for certain).

I would like to suggest either adding something to the option labels to indicate that they force the use of an old version of Jabber, or adding a separate check box to force it. The second option would be better, at least in relation to the "Override default server information" option since it is possible for the jabber service to run on a differen (sub)domain than the one the JID points to (e.g. the JID might say someone@somewhere.net but the actual service could be hosted at jabber.somewher.net). This shouldn't really be necessary since any service that "plays by the rules" will have SRV records available in the DNS info, but unfortunately "playing by the rules" is not something that can be relied on in every case.

Comment 9 Slávek Banko 2018-06-18 07:10:40 CDT

Descriptions for connection options added in GIT hash 44916473 (master) and 92f11c11 (r14.0.x).