This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 928913

Summary: Empathy fails to connect to Google Talk
Product: [Fedora] Fedora Reporter: Stef Walter <stefw>
Component: p11-kitAssignee: Kalev Lember <kalevlember>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: bdpepple, kalevlember, kengert, mclasen, satellitgo, stefw, tmraz, uraeus
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-29 05:01:03 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 466626    

Description Stef Walter 2013-03-28 13:41:48 EDT
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) 2013-03-28 15:26:08 EDT
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) 2013-03-28 16:01:10 EDT
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) 2013-03-28 16:05:19 EDT
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) 2013-03-28 16:11:47 EDT
> - 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 16:27:21 EDT
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) 2013-03-28 19:35:31 EDT
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) 2013-03-28 19:45:41 EDT
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) 2013-03-28 19:46:15 EDT
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 04:46:13 EDT
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 05:01:03 EDT
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