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.
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 ;-)
Jabber Plugin already support TLS/SSL connection. Install qca-tls package from your distribution and follow the intrustion pointed out by Till.
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.
this with be in theory fixed with the next version of libiris
Works for me.
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): require-starttls 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 ?
Reopening as per comments.
*** Bug 151947 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
AOL requires TLS for their new Jabber based ICQ/AIM services. And I can't connect to them with Kopete 0.50 :(
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.
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.
PS: This happens with qca-tls installed.
Seems like this would be a non-issue if Kopete was built on top of libpurple like Pidgin and AdiumX are...
This problem ist still in 3.5.10. wireshare sniffing: out: <?xml version="1.0"?> <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="jabber.org" > in: <?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
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?
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.
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.
4.2.1 still has this issue...
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 192.168.2.10:42305 -> 192.168.40.6:5222 [AP] <?xml version='1.0' ?> ## T 192.168.2.10:42305 -> 192.168.40.6:5222 [AP] <stream:stream to='jabberhost.de' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> ## T 192.168.40.6:5222 -> 192.168.2.10:42305 [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' xml:lang='en'> ## T 192.168.40.6:5222 -> 192.168.2.10:42305 [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 192.168.2.10:42305 -> 192.168.40.6:5222 [AP] <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> # T 192.168.40.6:5222 -> 192.168.2.10:42305 [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 192.168.2.10:49845 -> 192.168.40.6:5222 [AP] <?xml version="1.0"?>.<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="jabberhost.de" >. ## T 192.168.40.6:5222 -> 192.168.2.10:49845 [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> #####
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). :-(
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. http://xmpp.org/rfcs/rfc3920.html#tls # 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).
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.
Thanks for the feedback, that sounds very promising!
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! :-)
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.
(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.
DeathWing00, have you tried to remove and re-add your account in Kopete ? Which server is your JID using ?
(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)
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).
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.
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.
Thanks for the clue. After adding the SRV records, kopete works like a charm.