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.
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.
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?
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.)
> - 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.
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.
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.
I also reported this issue at https://bugzilla.gnome.org/show_bug.cgi?id=645133 which apparently had dealt with a similar issue before.
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"
This is a bug in p11-kit. Fixed upstream at: https://bugs.freedesktop.org/show_bug.cgi?id=62896
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