empathy throws untrusted certificate warning on google chat services using google apps (non-google domains)

[David J. Lennon]

Binary package hint: empathy

On Ubuntu 10.10, Empathy will throw an 'untrusted certificate, proceed?' warning during log-on for the Google Chat service when the user is using Google Apps and not a standard gmail.com / googlemail.com / google.com email address.

As an example, my Google Chat address uses Google Apps (google services through personally owned domains) and is <email address hidden>, and empathy expects the certificate hostname to match the 'justsomeboy.com' domain and not the google domain.

The error thrown is:

This connection is untrusted. Would you like to continue anyway?

The identity provided by the chat server cannot be verified. The hostname verified by the certificate doesn't match the server name.

Expected hostname: justsomeboy.com
Certificate hostname: talk.google.com

This is a recent change, earlier Maverick builds didn't throw this message. As there is no way on the Google Apps service to include certificates, this trusting check potentially should be disabled for the Google Chat service.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: empathy 2.31.92-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-21.31-generic 2.6.35.4
Uname: Linux 2.6.35-21-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Wed Sep 15 23:38:14 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386 (20100901.1)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: empathy

[flowbot (flowbot)]

affects me too on Xubuntu 10.10 beta.

[Brian Curtis (bcurtiswx)]

Thanks for your bug report and helping to make Ubuntu better. This is probably a jabber issue. First if you haven't, try it with jabber and not google talk and see if yu can reproduce this. Secondly, please provide telepathy logs (done by going to Help-->Debug and selecting gabble.) after reproducing this issue.

[Kenneth O'Brien (kobrien)]

I believe this is because the certificate is signed for Google and not for the end user domain. So is this not expected behaviour?

[David Gee (cdhgee)]

No, this is not the expected behaviour. In Ubuntu 10.04, this warning did not appear. This error seems to be restricted to Google Talk accounts hosted through Google Apps, which allows the use of one's own domain name. The certificate served by Google however has the talk.google.com domain name, which doesn't match the actual domain name, so the warning is shown.

I'm not sure why this has suddenly started happening in Maverick. I've attached the gabble debug log.

Regards
David

[David Gee (cdhgee)]

I have discovered a workaround: In Empathy > Edit > Accounts, check "Ignore SSL certificate errors" for each Google Apps Talk account. This suppresses the warning. However, this is not an ideal solution.

[Simon (simon-west-family)]

I had to also check "Use old SSL" as my Gtalk account said "Network Error" without that checked. No idea why but as the "override Server Settings" part of the dialogue says to use talk.google.com the cert error should not appear (the cert is from that server)

[Kai Groner (kai-gronr)]

I have this problem as well. This is with a jabber account configured to use the server talk.google.com.

[Andrew Cowie (afcowie)]

It's not a Google specific problem. We use a perfectly sound CAcert certificate and suddenly, on upgrade to Maverick, this warning started appearing. Really annoying. As stated above, "ignore SSL errors" is not ideal; there's nothing wrong with the cert. So, maybe there's a problem with the root certificate chains now, or the GIO code which walks them?

AfC

[Alejandro Mery (amery)]

the client must validate the name of the host in SRV, not against the domain name using it

[Alejandro Mery (amery)]

@Brian Curtis: the requested log (gabble) includes personal information so It can not be posted here. who should I mail it to?

[Martin Ling (martin-launchpad)]

This problem is still occuring, for any Jabber account where the server name in the certificate is not exactly the same as the Jabber domain name being used.

E.g. you have a valid certificate for jabber.example.com, which serves @example.com accounts. When you connect, you get:

The identity provided by the chat server cannot be verified.
The hostname verified by the certificate doesn't match the server name.
Expected hostname: example.com
Certificate hostname: jabber.example.com

There are two problems here.

First, empathy is ignoring the fact that Jabber service for example.com has been properly delegated to jabber.example.com via a SRV record:

_xmpp-server._tcp.example.com has SRV record 0 0 5269 jabber.example.com

Secondly, although the user is allowed to accept this mismatch, empathy does not remember this decision, so the problem recurs at every reconnect.

[Omer Akram (om26er)]

thanks for the bug report. please attach a screenshot of the issue so that we could send it to people writing the software.

[CryNGRoad (nathan-cryroad)]

Here's a screenshot of the issue on 10.10 for me:

[David Gee (cdhgee)]

Screenshot running under maverick.

[Alex Wauck (awauck)]

I have a hunch about what's going on here. I suspect that Telepathy is not using the custom server setting. I have experienced this myself. When I set up my account, I tell it to use <email address hidden> with the server jabber.domain.org. However, when it attempts to connect, it connects to domain.org! jabber.domain.org is an A record, not a CNAME. Empathy then complains that the certificate says jabber.domain.org when it expected domain.org. This is in Natty, by the way. My only Maverick machines run Kubuntu, so I use Kopete there. It connects without complaint.

[Alex Wauck (awauck)]

Also, Pidgin connects without complaint on the same machine on which Empathy fails.

[Alex Wauck (awauck)]

Hmm...since jabber.domain.org and domain.org have the same IP address, I guess lsof -i isn't a good way to determine what telepathy-gabble/empathy thinks it's connecting to. Durr...I should have known better than that. New hunch: Telepathy is using the custom server setting (or SRV record) to determine what to connect to, but it is not updating the TLS verifier accordingly.

[Alex Wauck (awauck)]

So, after a conversation with sjoerd on #empathy, it looks like it is the developers' intent that empathy expect a certificate from domain.org when connecting to the account <email address hidden>, even if the actual server being connected to is jabber.domain.org. I think the same thing is happening with Google Talk for Google Apps domains. I have a hard time accepting this as the correct way to handle this, especially since Pidgin and Kopete don't complain.

Everybody having trouble with Google Talk using a Google Apps domain account, try Pidgin and Kopete. If they both connect without complaint, then I would say that is evidence that Empathy is doing the wrong thing.

[Alex Wauck (awauck)]

Bah! Take a look at item 8 in section 5.1 of the XMPP spec (http://xmpp.org/rfcs/rfc3920.html#tls):
"Certificates MUST be checked against the hostname as provided by the initiating entity (e.g., a user), not the hostname as resolved via the Domain Name System; e.g., if the user specifies a hostname of "example.com" but a DNS SRV (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) [SRV] lookup returned "im.example.com", the certificate MUST be checked as "example.com". If a JID for any kind of XMPP entity (e.g., client or server) is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] (CCITT, “Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1),” 1988.) Object Identifier "id-on-xmppAddr" specified in Section 5.1.1 (ASN.1 Object Identifier for XMPP Address) of this document. "

In other words, when Empathy/Telepathy attempts to connect as <email address hidden>, it is right to check for a certificate for gappdomain.com instead of talk.google.com.

So, the real question here is this: should Empathy/Telepathy bend the rules here? I think it would be reasonable to accept a certificate for the domain specified in the Jabber ID _OR_ the server we are actually connecting to.

[Alex Wauck (awauck)]

More from sjoerd: apparently, the Google Talk people have been working with the XMPP spec people to resolve this issue. Hopefully, this will get resolved eventually. Until then, I don't think upstream will be inclined to work around it, so perhaps Ubuntu should carry a patch? Perhaps we could restrict the "accept either certificate" behavior to Google Talk accounts.

[David Gee (cdhgee)]

As per comment #19, I tested pidgin. It gave an equivalent error about not being able to validate the certificate, see screenshot

[Markus Nicolussi (mcwimpy)]

thank you Alex (#21) - I got the same issue here on Natty (Ubuntu 11.04) - any updates? will there be a patch soon?

[Vladimir Scherbaev (zemik)]

Confirmed for last 11.10

[David Gomes (davidgomes)]

I can also confirm for 11.10.

[Antono Vasiljev (antono)]

Same here on 11.10

[Antono Vasiljev (antono)]

probably its duplicate of https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/828756

[Launchpad Janitor (janitor)]

[Expired for empathy (Ubuntu) because there has been no activity for 60 days.]

[Eugene Minov (minov-eug)]

Hi,

I know that it's an old bug report but I've got exact same problem in Ubuntu 12.10 when installed and logged into LXDE desktop manager.

#sudo apt-get install lxde

Before installing lxde all was ok.
And I use empathy only with google account.
Ubuntu 12.10 Amd64.