Pidgin not using existing root TLS/SSL certificates for validation

[Bryan C]

Binary package hint: pidgin

After upgrading to Pidgin 1:2.4.1-1ubuntu2.2 for Ubuntu 8.04.1, attempting to connect to Google talk or MSN Messenger results in Pidgin asking me to verify that the SSL certificates provided are valid. While it is good that Pidgin is not blindly accepting invalid certificates anymore, some of the supposed invalid certificates are apparently issued by root certificates that are provided by the ca-certificates package. It would be an improvement if Pidgin had access to some root certificates to validate against so that users do not have to manually accept every certificate.

I did a bit of Googling and found a Debian bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492434) notes that Pidgin 2.4.1 does not look in "/etc/ssl/certs" for certificates - it looks in "etc/ssl/certs" (a relative path) instead. Later versions of Pidgin apparently support a "--with-system-ssl-certs" configure option, but the approach taken for that Debian bug was to apply a patch to fix the hardcoded path (see http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=32;filename=debian-ca-certs.patch;att=1;bug=492434).

Below I have provided descriptions of what I expected to happen and what actually happens when I try to connect to Google Talk and MSN Messenger via Pidgin 1:2.4.1-1ubuntu2.2.

---

When connecting to Google Talk:
Expected behaviour: able to connect without any certificate warnings

Actual behaviour: when attempting to connect, I receive the following prompt (buttons in brackets):
  Accept certificate for talk.google.com?
  The root certificate this one claims to be issued by is unknown to Pidgin.
  (View Certificate...) (Reject) (Accept)

Workaround: since Pidgin is looking for "etc/ssl/certs" instead of "/etc/ssl/certs", and since Pidgin's current working directory when launched from the applications menu is the user's home directory, if I create a symlink from ~/etc to /etc then Pidgin connects without asking me to validate the certificate (I assume this is due to it being able to validate the certificate).

---

When connecting to MSN Messenger:
Expected behaviour: able to connect without any certificate warnings

Actual behaviour: when attempting to connect, I receive the following prompt (buttons in brackets):
  Accept certificate for nexus.passport.com?
  The root certificate this one claims to be issued by is unknown to Pidgin.
  (View Certificate...) (Reject) (Accept)

Behaviour with the above workaround: after creating a symlink from "~/etc" to "/etc", I get the following prompt instead:
  Accept certificate for login.live.com?
  The root certificate this one claims to be issued by is unknown to Pidgin.
  (View Certificate...) (Reject) (Accept)

It appears that with the symlink workaround, Pidgin is able to validate the certificate for nexus.passport.com, but not for login.live.com. There exists a closed Pidgin bug (http://developer.pidgin.im/ticket/7002) that claims that login.live.com is not accepted because the Ubuntu ca-certificates package is missing some root certificates that Pidgin supplies (but are apparently not distributed with Ubuntu's Pidgin package); Firefox, however, accepts the certificate presented by https://login.live.com... I'm not sure what that would imply.

[Bryan C (bry111)]

As an aside, if someone else who is affected by this bug attempts the workaround I provided in the bug description to connect to Google Talk, and Pidgin warns that "the certificate presented by 'talk.google.com' claims to be from 'gmail.com' instead", you might be connecting to incorrect (obsolete?) ports. Go to Accounts->Manage, select your Google Talk account and click "Modify", and on the "Advanced" tab, and try the following settings (they worked for me):

Check "Require SSL/TLS"
Check "Force old (port 5223) SSL"
Uncheck "Allow plaintext auth over unencrypted streams"
Uncheck "Use GSSAPI (Kerberos v5) for authentication"

Set the "Connect port" to 443
Set the "Connect server" to talk.google.com

I suppose this comment doesn't relate to this bug other than that I ran into the problem described in this comment while trying to work around the problem described by this bug. I hope it helps someone else. Sorry if this is the wrong place to post such a comment.

[Barak (barak-naveh)]

any workaround for the certificate of login.live.com ?
is it safe to accept it?

[Bryan C (bry111)]

If Pidgin doesn't know whether the certificate is valid or not, you could be vulnerable to a man-in-the-middle attack by blindly accepting it (at least that's my understanding). Mind you, accepting it yourself without any other knowledge would be no worse than what Pidgin was doing before version 1:2.4.1-1ubuntu2.2 was released (it was blindly accepting all certificates without asking - see bug 251304), but personally I'd rather not take that approach.

I have found a simple workaround for login.live.com, that should be safe (as long as you trust the root certificates that Firefox uses).

First, navigate Firefox to https://login.live.com/.
For me, at least, Firefox accepts the certificate as being verified by VeriSign; you should bail out here if Firefox complains about an invalid certificate.
View the page's certificate (right-click the page, select "View Page Info", click the security icon, and click the "View Certificate" button).
On the "Details" tab, click the "Export..." button.

As of this point, I'm working from memory (don't have access to my home machine at the moment), so hopefully I get the details right.
You'll want to save the certificate with a file name of "login.live.com" as type "X.509 Certificate (PEM)" (at the very least, I remember that the default type worked for me) in "~/.purple/ssl/certs". You might need to right-click in the file list and show hidden files to see the ".purple" directory in your home directory. I'm not sure about the exact path; it might have been "~/.purple/ssl/ca-certs" instead. In any case, the directory should exist if you've started Pidgin before; you just need to drop in the certificate with a filename of the host it belongs to (no extra ".pem" extensions or anything like that).

Once you've done all that, restart Pidgin and it should accept login.live.com. You may need to disable and re-enable your MSN account (in "Accounts->Manage Accounts") if Pidgin doesn't bother trying to connect because it was previously deemed invalid.

I'm sure you could use other tools, or browsers instead of Firefox, to export the certificate... but this approach worked for me. I hope this is helpful until an official fix is released.

[komputes (komputes)]

I can confirm having an issue with an MSN account. Pidgin is asking me if I will "Accept certificate from rsi.hotmail.com" This all started at the begining of the week and happens from multiple different internet connections.

[Bryan C (bry111)]

To correct my previous comment (https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/302314/comments/3), the path to place the login.live.com certificate (or any other certificate you want Pidgin to accept per-user) is
~/.purple/certificates/x509/tls_peers/

Sorry for the confusion. I was thinking of /etc/ssl/certs instead. You probably don't want to just dump certificates in there.

To emphasize, making symlinks in your home directory or dumping trusted certificates in ~/.purple are just crude short-term workarounds to avoid accepting untrusted certificates because of a bug. They aren't long-term solutions.

komputes: I haven't had any issues with rsi.hotmail.com, though according to http://developer.pidgin.im/ticket/6680 you might have offline messages that aren't getting through. Apparently MSN uses a different host and a different certificate for offline messages. Until an official fix for Ubuntu is released you could perform the Firefox workaround I suggested above for login.live.com with rsi.hotmail.com, or you could find another way to verify the certificate (there are some instructions on using openssl and a certificate in the Pidgin ticket; it appears to be out of date though), or you could just accept the certificate if you're feeling lucky (though I wouldn't recommend it).

[Barak (barak-naveh)]

Hey Bryan, thanks for the workaround.

[Bernard_Ivo (bernard-abv)]

Hi, I can confirm I have the same problem connecting to Gtalk for a week already.

Common name: gmail.com
Fingerprint (SHA1): 9f:f8:3b:da:2c:a3:12:55:24:d5:b9:d6:fc:49:69:8f:0a:91:d8:cd
Activation date: Wed Apr 11 20:17:38 2007
Expiration date: Tue Apr 10 20:17:38 2012

Somehow it takes too long to release a fix, will probably try the workaround.

Cheers

[tobiasly (tobiasly)]

I would like to add another data point to this issue. I was having the same issue as Bernard_Ivo in that I kept getting asked whether to accept the talk.google.com certificate each time I started pidging. I have a talk.gmail.com certificate in ~/.purple/certificates/x509/tls_peers already so I didn't understand why I was getting the error. Creating the etc symlink in my home directory didn't resolve the issue.

Then I deleted talk.gmail.com cert and restarted Pidgin. It then asked me *twice* about the Gmail cert! Then I realized: I have two Gmail talk accounts (one Gmail, the other Google Apps). I disabled one of the two, restarted Pidgin, and got to warning. I closed and restarted again to verify that I still got no warning.

So then I re-enabled both accounts, deleted talk.google.com cert and restarted. I verified that the two "talk.google.com" certificates were *different*. One came from gmail.com and one came from talk.google.com. So the root problem here seems to be that the connection server is being redirected based on whether you're using Google Apps or Gmail, and Pidgin stores the cert based on the name of the initial server, not the one that is actually performing SSL.

So, for those that are also having this problem, do you have 2 different Gmail/Google Apps accounts as well?

As an aside, following Bryan C's fix (comment #1 from 2008-11-26) fixed this problem. These accounts were both originally connecting to port 5223; I switched to force SSL connection to port 443 for both of them and no longer get a warning for either one.

[Gustav Svensson (gustav-svensson)]

tobiasly wrote:
So, for those that are also having this problem, do you have 2 different Gmail/Google Apps accounts as well?

Yes. I guess that is what is causing the problem. Bryan C's workaround fixes the problem for me as well.

[Brian Candler (b-candler)]

The problem definitely remains.

This morning, pidgin under Hardy started giving me the 'invalid certificate' error for login.live.com, asking me blindly whether or not to accept the new certificate. It showed me nothing more than the fingerprint and start/end times to make that choice.

Coincidentally, update manager showed me an update to pidgin, but even after update the error persisted. I now have:

ii libpurple0 1:2.7.0-0ubuntu1.1~pidgin1.08.04 multi-protocol instant messaging library
ii pidgin 1:2.7.0-0ubuntu1.1~pidgin1.08.04 graphical multi-protocol instant messaging client for X
ii pidgin-data 1:2.7.0-0ubuntu1.1~pidgin1.08.04 multi-protocol instant messaging client - data files
ii pidgin-otr 3.1.0-1 Off-the-Record Messaging plugin for pidgin

The error also continued after deleting the existing login.live.com certificate from within pidgin.

I initially rejected the certificate, on the basis that there might be an upstream device intercepting, logging and/or modifying the traffic.

However I was able to verify the certificate manually like this:

(1) openssl s_client -CApath /etc/ssl -connect login.live.com:443

This showed that the certificate is indeed valid and signed by a trusted CA (verify return code 0 = OK)

(2) Copy-paste the PEM certificate shown from step 1 into a new file (ll.cert)

(3) Take the fingerprint of that certificate:

openssl x509 -in ll.cert -noout -fingerprint
> SHA1 Fingerprint=C9:F2:FD:50:A2:0C:AB:4A:45:22:F9:23:E1:91:04:9E:01:F0:64:48

(4) This value matches the value shown by pidgin, so I was able to accept it safely

It's pretty ridiculous that an end-user has to go to such extremes to ensure the security of their comms, when all the machinery and the trust root needed to validate it is already present within Ubuntu.

[Pedro Villavicencio (pedro)]

Thanks for the report, it has been some time without any response or feedback in this bug report and we are wondering if this is still an issue for you with the latest release of Ubuntu the Natty Narwhal, May you please test with that version and comment back if you're still having or not the issue? Please have a look at http://www.ubuntu.com/download to know how to install that version.Thanks in advance.