Bug 928913 - Empathy fails to connect to Google Talk
Summary: Empathy fails to connect to Google Talk
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: p11-kit
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 466626
TreeView+ depends on / blocked
 
Reported: 2013-03-28 17:41 UTC by Stef Walter
Modified: 2013-03-29 09:01 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-29 09:01:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 62896 0 None None None Never

Description Stef Walter 2013-03-28 17:41:48 UTC
With the new shared system certificates, Empathy fails to connect to Google Talk. 

This is Fedora 19 TC2.

To replicate the issue:

Go to gnome-control-center -> "Online Accounts" -> "Add Account" -> "Google". Type user name, password, complete account setup.

Then go into 'empathy' and see the invalid certificate warning.

I'll fine tune the component for this bug once we figure out what's causing it.

Comment 1 Kai Engert (:kaie) (inactive account) 2013-03-28 19:26:08 UTC
This problem isn't caused by us.
I believe it's because the google talk service uses a cert that doesn't match the required hostname.

I was able to show that empathy fails to connect using packages that doesn't involve any of our new work:

- download 
  http://kojipkgs.fedoraproject.org//packages/ca-certificates/2012.87/1.fc18/noarch/ca-certificates-2012.87-1.fc18.noarch.rpm

- rpm -Uvh --oldpackage ca-certificates-2012.87-1.fc18.noarch.rpm

- yum erase p11-kit-trust

Now start empathy, and the connection to google talk will still fail.

Comment 2 Kai Engert (:kaie) (inactive account) 2013-03-28 20:01:10 UTC
I'm changing this to the empathy component for now.

This isn't a bug in empathy in my opinion, this is mostly a FYI.
I believe google uses an unfortunate configuration, at least based on my current understanding.

I see that empathy starts a DNS request for talk.google.com.
That has two important results:
- 127.0.0.2
- alias for talk.l.google.com

Because the first result won't allow a connection, the alias is tried. I can see empathy querying for the talk.l.google.com hostname, which resolves to an IP, and a connection is established.

However, the certificate sent by the google server allows the hostname talk.google.com, only.

As a result, the SSL/TLS engine being used by empathy probably rejects the certificate because of the hostname mismatch.

BTW, why does google still use 1024 bit keys for TLS?

Comment 3 Kai Engert (:kaie) (inactive account) 2013-03-28 20:05:19 UTC
BTW, empathy doesn't offer to dump the cert.
I was able to get a dump of it using:

openssl s_client -starttls xmpp -showcerts -verify 5 -connect talk.l.google.com:5222

(Note that this openssl command line tools reports "verify ok", that's because it doesn't check the hostname to match.)

Comment 4 Kai Engert (:kaie) (inactive account) 2013-03-28 20:11:47 UTC
> - 127.0.0.2

This was caused by an old local configuration I had in my /etc/hosts file for testing...

So, Ryan Sleevi from Google proposed that the client should do the certificate validation against the original hostname, even if the host got redirected.

So, after all, it might indeed be a bug in empathy?

We should figure out how the certificate validation gets called, using which hostname, using which cert.

Comment 5 Tomas Mraz 2013-03-28 20:27:21 UTC
The certificate should be verified against the original requested DNS name and not the resolved name/address. This is clear. So that means a bug in empathy.

Comment 6 Kai Engert (:kaie) (inactive account) 2013-03-28 23:35:31 UTC
After quite a bit of learning how to debug empathy, I was able to find that telepathy-gabble calls:

gabble_server_tls_manager_verify_async (handler=0x715a00, tls_session=0x723180, peername=0x733fb0 "gmail.com", extra_identities=0x0, callback=0x7ffff7b9b5f0 <tls_handler_verify_async_cb>, user_data=0x7ffff0013aa0) at server-tls-manager.c:334

It correctly avoids the dns alias name (talk.l.google.com or similar), but it uses "gmail.com" as the hostname, which doesn't match the cert.

I couldn't find out WHY it uses gmail.com - I suspect it does so based on the login ID used.

Looking at .local/share/telepathy/mission-control/accounts.cfg
it even contains something like
  param-extra-certificate-identities=talk.google.com;

And the only mention of gmail.com is in my login id / email address. 

We need someone understanding the empathy architecture to figure out why it uses "gmail.com" as the point of contact, instead of "talk.google.com" which seems to be what they actually expect to be used, based on the cert.

Comment 7 Kai Engert (:kaie) (inactive account) 2013-03-28 23:45:41 UTC
I also reported this issue at https://bugzilla.gnome.org/show_bug.cgi?id=645133
which apparently had dealt with a similar issue before.

Comment 8 Kai Engert (:kaie) (inactive account) 2013-03-28 23:46:15 UTC
FYI, larger stack:

(gdb) bt
#0  gabble_server_tls_manager_verify_async (handler=0x715a00, tls_session=0x723180, peername=0x733fb0 "gmail.com", extra_identities=0x0, callback=0x7ffff7b9b5f0 <tls_handler_verify_async_cb>, user_data=0x7ffff0013aa0) at server-tls-manager.c:334
#1  0x00007ffff7b9b073 in session_handshake_cb (source=<optimized out>, res=<optimized out>, user_data=0x7ffff0013aa0) at wocky-tls-connector.c:339
#2  0x0000003b32a6b4e7 in g_simple_async_result_complete (simple=0x7785d0) at gsimpleasyncresult.c:777
#3  0x00007ffff7ba07ba in wocky_tls_job_result_boolean (result=0, job=<optimized out>) at wocky-tls.c:382
#4  wocky_tls_session_try_operation (session=<optimized out>, operation=<optimized out>) at wocky-tls.c:414
#5  0x0000003b32a581da in async_ready_callback_wrapper (source_object=0x75bb00, res=0x719900, user_data=0x723180) at ginputstream.c:530
#6  0x0000003b32a7776b in g_task_return_now (task=0x719900) at gtask.c:1105
#7  0x0000003b32a77789 in complete_in_idle_cb (task=0x719900) at gtask.c:1114
#8  0x0000003b31647f46 in g_main_dispatch (context=0x70eb70) at gmain.c:3054
#9  g_main_context_dispatch (context=context@entry=0x70eb70) at gmain.c:3630
#10 0x0000003b31648298 in g_main_context_iterate (context=0x70eb70, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701
#11 0x0000003b3164869a in g_main_loop_run (loop=0x71c680) at gmain.c:3895
#12 0x0000003b3374cf12 in tp_run_connection_manager (prog_name=prog_name@entry=0x4a4733 "telepathy-gabble", version=version@entry=0x4abcad "0.17.3", construct_cm=construct_cm@entry=0x426a60 <construct_cm>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe338) at run.c:285
#13 0x0000000000426d3c in gabble_main (argc=1, argv=0x7fffffffe338) at gabble.c:179
#14 0x0000003fcd821b75 in __libc_start_main (main=0x426950 <main>, argc=1, ubp_av=0x7fffffffe338, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe328) at libc-start.c:258
#15 0x0000000000426999 in _start ()

(gdb) bt 5 full
#0  gabble_server_tls_manager_verify_async (handler=0x715a00, tls_session=0x723180, peername=0x733fb0 "gmail.com", extra_identities=0x0, callback=0x7ffff7b9b5f0 <tls_handler_verify_async_cb>, user_data=0x7ffff0013aa0) at server-tls-manager.c:334
        self = <optimized out>
        certificate = <optimized out>
        result = <optimized out>
        __PRETTY_FUNCTION__ = "gabble_server_tls_manager_verify_async"
#1  0x00007ffff7b9b073 in session_handshake_cb (source=<optimized out>, res=<optimized out>, user_data=0x7ffff0013aa0) at wocky-tls-connector.c:339
        error = 0x0
        tls_conn = 0x770d40
        self = 0x7ffff0013aa0
        tls_type = <optimized out>
        __PRETTY_FUNCTION__ = "session_handshake_cb"
#2  0x0000003b32a6b4e7 in g_simple_async_result_complete (simple=0x7785d0) at gsimpleasyncresult.c:777
        current_source = 0x1189ea0
        current_context = 0x478650 <gabble_server_tls_manager_verify_async>
        __PRETTY_FUNCTION__ = "g_simple_async_result_complete"
#3  0x00007ffff7ba07ba in wocky_tls_job_result_boolean (result=0, job=<optimized out>) at wocky-tls.c:382
        simple = 0x7785d0
#4  wocky_tls_session_try_operation (session=<optimized out>, operation=<optimized out>) at wocky-tls.c:414
        result = 0
        __PRETTY_FUNCTION__ = "wocky_tls_session_try_operation"

Comment 9 Stef Walter 2013-03-29 08:46:13 UTC
This is a bug in p11-kit. Fixed upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=62896

Comment 10 Stef Walter 2013-03-29 09:01:03 UTC
Pulled the patch from upstream into 0.17.5-2. Build in progress for f19. Will be available shortly: http://koji.fedoraproject.org/koji/taskinfo?taskID=5186790


Note You need to log in before you can comment on or make changes to this bug.