Bug 294369

Summary:	Telepathy/KDE XMPP component allows connections with certificate errors when require-encryption is disabled
Product:	[Frameworks and Libraries] telepathy	Reporter:	Dennis Schridde <dschridde+kde>
Component:	auth-handler	Assignee:	Telepathy Bugs <kde-telepathy-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	ddomenichelli, kde, mklapetek, stth1998, yofel
Priority:	NOR
Version:	0.3.0
Target Milestone:	Future
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	0.6.0
Bug Depends on:	265315
Bug Blocks:

Description Dennis Schridde 2012-02-18 15:14:52 UTC

Version:           0.3 (using KDE 4.7.4) 
OS:                Linux

See below for the problem description.

Note: Variable names are made up and were chosen because I had to translate from german. Please ask me for the german string if there is any uncertainty about the identity of a setting.

Reproducible: Always

Steps to Reproduce:
require-encryption=yes, ignore-certificate-errors=no -> Try to connect results in a certificate error.

Set require-encryption=no and try to connect -> Wireshark shows an encrypted connection, but there was no certificate error.


Expected Results:  
Telepathy should abort due to the certificate error.

Comment 1 Dennis Schridde 2012-02-18 15:18:30 UTC

The problem is with the XMPP component of Telepathy/KDE.

Comment 2 Dennis Schridde 2012-02-18 15:51:03 UTC

Re bug #265315: I do not get any window at all (not even a GTK window).

Also note that IMO the problem is not (only) that the certificate error is not reported in the UI, but that the connection is accepted at all, ignoring the ignore-certificate-errors setting. Might be a bug in Telepathy/Gabble. Version used is 0.13.5.

Comment 3 Martin Klapetek 2012-02-18 15:52:56 UTC

The related bug is actually a wish to implement full TLS channel handling, this will ultimately fix your issue. Until that handler is done, we can't (won't) do much about it.

Comment 4 David Edmundson 2012-02-23 01:35:38 UTC

This still sounds wrong. If the TLS handler isn't available it should fail. 

I'm sure I've seen it fail to connect until I've unticked "require encrypted connection".

The TLS handler will make this less relevant, but this would still be a bug (albeit upstream)

could you check everything is set as you described.
Ideally with the output of 

mc-tool show ID OF MY ACCOUNT

(where ID OF MY ACCOUNT is found using mc-tool list)

Comment 5 Dennis Schridde 2012-02-23 09:06:42 UTC

(In reply to comment #4)
> This still sounds wrong. If the TLS handler isn't available it should fail. 
>
> The TLS handler will make this less relevant, but this would still be a bug
> (albeit upstream)
That's what I'd think, too.

> I'm sure I've seen it fail to connect until I've unticked "require encrypted
> connection".
Confirming that.

> could you check everything is set as you described.
I am unsure what you want - especially since you can reproduce it yourself. When I reported this bug, I ran quite a few tests until I figured this out - so I don't know what new thing to check.
Btw: The setting I referred to as ignore-certificate-errors is named ignore-ssl-errors in Gabble.

Comment 6 stefan 2012-11-02 13:53:50 UTC

the problem persists in version 0.5.1 (kde 4.9.2)

xmmp -> tested with jabber.ccc.de and jabber.org on existing accounts with standard properties.

ialways require encryption. if i tick "ignore ssl errors" it works, if i untick "ignore ssl errors" it doesnt work.

So don't tell us, the tsl/ssl implementation doesn't work!

I also downloaded the server certificates and added them in the system properties under network & connections > ssl properties and (desperately) in the firefox cert store. nothing changed, even after reboot. I also found the signing root certificates in /etc/ssl/certs/.

Comment 7 Daniele E. Domenichelli 2012-11-02 15:06:16 UTC

This is going to be fixed in 0.6, for now to connect to servers with untrusted certificates it is necessary to set ignore-certificate-errors=yes

*** This bug has been marked as a duplicate of bug 265315 ***