Bug 112213 - XMPP Jabber TLS support
Summary: XMPP Jabber TLS support
Alias: None
Product: kopete
Classification: Applications
Component: Jabber Plugin (show other bugs)
Version: 0.40.0
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Kopete Developers
: 151947 (view as bug list)
Depends on:
Reported: 2005-09-08 10:33 UTC by Rene Horn
Modified: 2009-08-07 20:42 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Rene Horn 2005-09-08 10:33:12 UTC
Version:           0.10.3 (using KDE 3.4.2, Debian Package 4:3.4.2-3 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.12witchblade

I would like to see support for TLS encryption.  This would allow Kopete to work with Google Talk and other Jabber servers that use it.  It seems that it's becoming the popular option over SSL.
Comment 1 Till 2005-09-08 10:41:22 UTC
It's already there. It is possible, that you dont have the qca-tls package installed. check http://wiki.kde.org/tiki-index.php?page=Google%20Talk%20support for details.

And now go ahead and close this bug ;-)
Comment 2 Michaël Larouche 2005-09-08 13:00:39 UTC
Jabber Plugin already support TLS/SSL connection.
Install qca-tls package from your distribution and follow the intrustion pointed out by Till.
Comment 3 Manuel McLure 2005-11-04 06:35:32 UTC
The web site that's referred to above shows how to get SSL working to Google Talk - *not* TLS. TLS (i.e. automatic STARTTLS over the standard Jabber port) doesn't seem to work with Kopete - it just hangs forever if the server doesn't allow plaintext authentication. Gaim connects to the same server without any problems. If a server has not enabled the legacy 5223 SSL port, you're SOL.
Comment 4 Olivier Goffart 2005-11-04 08:52:23 UTC
this with be in theory fixed with the next version of libiris 
Comment 5 Rene Horn 2006-03-29 19:13:37 UTC
Works for me.
Comment 6 Chris Samuel 2007-07-12 07:20:54 UTC
I can confirm that this bug still exists with the current version of Kopete (0.12.5) in KDE 3.5.7 packaged for Kubuntu as 3.5.7-0ubuntu1~feisty1.

I cannot connect to jabberd2 v 2.1.6 when it is configured to only accept TLS (not SSL) connections using STARTTLS.

The config file option that was set on the server says (I am told):

        If this is enabled, clients must do STARTTLS
        before they can authenticate. Until the stream is encrypted,
        all packets will be dropped.

If they disable that option and enable the legacy SSL support then I can connect successfully with Kopete.

I have qca-tls installed (packaged as 1.0-3) so it's not that.

Can this bug be reopened until it is finally fixed please ?
Comment 7 Pino Toscano 2007-11-09 12:40:40 UTC
Reopening as per comments.
Comment 8 Pino Toscano 2007-11-09 12:41:04 UTC
*** Bug 151947 has been marked as a duplicate of this bug. ***
Comment 9 Ralf Hildebrandt 2007-12-09 15:04:24 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 Gabriel Ambuehl 2008-01-19 12:09:48 UTC
AOL requires TLS for their new Jabber based ICQ/AIM services. And I can't connect to them with Kopete 0.50 :(
Comment 11 Jiann-Ming Su 2008-02-24 00:21:27 UTC
I'm using Kopete on Kubuntu 7.10 and am experiencing the same problem.  Two jabber servers I connect to require TLS.  I have no problems connecting with Pidgin and AdiumX, but Kopete will not connect.
Comment 12 Dennis Schridde 2008-04-12 23:07:14 UTC
This bug is still present in KDE 3.5.9.
When connecting to a jabber server (ejabberd-2.0.0 and also ejabberd-1.1.4), which is configured with starttls_required on port 5222, Kopete will fail with the cryptic "Im Protokollfluss ist ein Fehler aufgetreten: Verletzung der Regelungen im Protokollfluss" ~> "Error in protocol stream: Policy-violation in protocol stream".

The XML message sent by the Server says:
<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of STARTTLS required</text></stream:error>

(a) That problem with starttls should be fixed.
(b) The message should give some useful hint on what kind of policy violation happened.
Comment 13 Dennis Schridde 2008-04-12 23:08:07 UTC
PS: This happens with qca-tls installed.
Comment 14 Jiann-Ming Su 2008-04-21 05:35:24 UTC
Seems like this would be a non-issue if Kopete was built on top of libpurple like Pidgin and AdiumX are...
Comment 15 kdebugs4reinhard 2008-10-06 00:30:31 UTC
This problem ist still in 3.5.10.

wireshare sniffing:


<?xml version="1.0"?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="jabber.org" >

<?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='4044400753' from='jabber.org' xml:lang='en'><stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of STARTTLS required</text></stream:error></stream:stream>

AOL i.e. is working fine but jabber not

Comment 16 Johannes Truschnigg 2008-11-04 12:56:59 UTC
This is still an issue with both KDE 4.1.2 and 3.5.10, no matter on what additional libs are installed. I've neverprogrammed Qt nor KDE, but shouldn't there be some Qt-side support for STARTTLS anyway? That's at least what Google suggests when feeding it with appropriate terms. What's holding this particular feature back?
Comment 17 Rajko Albrecht 2008-11-12 08:48:17 UTC
Still here in kopete for kde 4.1.2, whats the matter that tls with kopete jabber isn't working but with clients like pidgin and so on? 

If there is a dependency to some other external cryptographic lib it should documented in help or popup in jabber configuration dialog.
Comment 18 Sverre Froyen 2009-01-06 21:29:25 UTC
As an FYI, I note that psi 0.11 works fine using starttls.  I believe psi is using substantially the same cryptographic libs and modules as kopete.
Comment 19 Dennis Schridde 2009-03-07 14:55:07 UTC
4.2.1 still has this issue...
Comment 20 kdebugs 2009-04-21 22:56:30 UTC
Yes, really annoying. I'd really like to see this bug fixed. This bug makes kopete unusable to me and many other users of XMPP servers which use the "STARTTLS" command. 

I cannot believe, it takes ages to fix this bug. This is what pidgin does:

T -> [AP]                                                                                                            
  <?xml version='1.0' ?>                                                                                                                                  
T -> [AP]                                                                                                            
  <stream:stream to='jabberhost.de' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>                                     
T -> [AP]                                                                                                            
  <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='105384129' from='jabberhost.de' version='1.0'
T -> [AP]                                                                                                            
  <stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism
  >PLAIN</mechanism></mechanisms><register xmlns='http://jabber.org/features/iq-register'/></stream:features>                                             
T -> [AP]                                                                                                            
  <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>                                                                                                     
T -> [AP]                                                                                                            
  <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>    

and from beyond that point any conversation is cryptet by SSL - as required by the server. But kopete instead doesn't seem even trying to start a conversation:

T -> [AP]
  <?xml version="1.0"?>.<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="jabberhost.de" >.
T -> [AP]
  <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='278883228' from='jabberhost.de' xml:lang='en'
  ><stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of START
  TLS required</text></stream:error></stream:stream>
Comment 21 Chris Samuel 2009-04-29 14:52:48 UTC
This problem is still present in 4.2.2 - it would be nice to get some feedback from the Kopete developers to at least know that they are aware of this issue and any thoughts they may have ?

Thanks to this bug I was locked out of the new Jabber.org.au server until I could persuade the admins to unblock 5223 for legacy clients (which I guess Kopete is now). :-(
Comment 22 Chris Samuel 2009-04-29 15:26:53 UTC
Can we get the severity of this bug upgraded please ?

I believe that this bug means Kopete is not correctly implementing the XMPP Jabber specification because it is claiming to support version "1.0" of XMPP but if it claims that then (if my reading of the XMPP site is correct) it needs to support STARTTLS.


# 3. When a receiving entity that complies with this specification
# receives an initial stream header that includes the 'version'
# attribute set to a value of at least "1.0", after sending a
# stream header in reply (including the version flag), it MUST
# include a <starttls/> element (qualified by the
# 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the
# list of other stream features it supports.

If (as seems possible) Kopete is using the same libraries for XMPP and TLS as Psi is (Iris and QCA-TLS) then I would have thought it would be possible to get the same level of support from them as Psi is.

If I ever get some free time I'll take a look at the code and see what I can suggest (if this bug hasn't already been solved by then).
Comment 23 Detlev Casanova 2009-04-29 16:26:38 UTC
This has been fixed in SVN since some times now (Olivier did that when he updated iris IIRC)

As it is a new feature since the release of KDE 4.2, you will have to wait for KDE 4.3 or use the latest SVN version.

If you use SVN, be careful that there is still a possibility to use the old protocol (xmpp09). That option is by default set to false but an old configuration file could make Kopete still use the old protocol.
The reason of support of the old protocol is simply because some servers don't implement the new protocol yet.
Comment 24 Chris Samuel 2009-05-03 13:52:16 UTC
Thanks for the feedback, that sounds very promising!
Comment 25 Chris Samuel 2009-05-17 14:08:06 UTC
I've now upgraded to KDE4.3 beta1 packaged in the Kubuntu experimental PPA and I can confirm that Kopete now auth's properly with TLS with the Jabber.org.au server.

Nice one folks, thanks for the fix! :-)
Comment 26 Deathwing00 2009-06-02 17:16:55 UTC
Can anyone point me to the proper patch for this? I have tried this in both 4.2.85 and 4.2.88 and kopete still fails to StartTLS.
Comment 27 Dennis Schridde 2009-06-02 17:43:44 UTC
(In reply to comment #26)
> Can anyone point me to the proper patch for this? I have tried this in both
> 4.2.85 and 4.2.88 and kopete still fails to StartTLS.
I can confirm that it works for me in 4.2.88.
Comment 28 Detlev Casanova 2009-06-02 17:52:15 UTC
DeathWing00, have you tried to remove and re-add your account in Kopete ?
Which server is your JID using ?
Comment 29 Deathwing00 2009-06-02 18:31:22 UTC
(In reply to comment #28)
> DeathWing00, have you tried to remove and re-add your account in Kopete ?
> Which server is your JID using ?

jabber.fluendo.com (ejabberd)
Comment 30 Deathwing00 2009-06-02 18:37:32 UTC
I tried removing the account from kopete and recreating it, and it worked! Apparently the problem occurs only if you override the default settings (even if the settings are the same).
Comment 31 Sverre Froyen 2009-08-07 16:32:22 UTC
I need to access a server where the user id is of the form name@domain.com and the hostname is host.domain.com.  This requires me to override the default hostname setting which in turn causes starttls not to be used.  Is there a patch that fixes this?  I'm using KDE4.3.0.
Comment 32 Detlev Casanova 2009-08-07 17:54:41 UTC
No, you don't have to override the default hostname setting. Kopete now supports SRV resolution.

If it's not the case, there is a bug somewhere.

Override the default hostname/port setting only if your server is old and does not support the "new" XMPP protocol.
Comment 33 Sverre Froyen 2009-08-07 20:42:46 UTC
Thanks for the clue.  After adding the SRV records, kopete works like a charm.