20

Pidgin started prompting me to accept/reject new gtalk SSL certificate a few days ago and I am not able at the moment to tunnel the traffic to check if it would continue to happen or if it wouldn't (which would mean an attempt of SSL MITM attack).

How (and where) can I check if the new SSL certificate is valid? Can I even do that? Is there a place with a list of certificates where I could compare them?

I found this question, but I am not sure if that is the answer I am looking for. Answers to that question say that it is clients job to validate the certificate, but what happens to me is that pidgin (in my case the client) tells me "The certificate for talk.google.com could not be validated. The certificate claims to be from "gmail.com" instead. This could mean that you are not connecting to the service you believe you are.". Now, I may be overparanoid but I would still really like to know how and if I can manually check this. Thank you.

Improve this question

7 Answers 7

Reset to default
13

The message you quote means: "I wanted to talk to a server called talk.google.com, but what responded there seems to use a certificate which has the name gmail.com in it, and not talk.google.com". This means that either of these is true:

  • some ill-intentioned third party is actively redirecting your connection to the wrong server, possibly by DNS poisoning;
  • some mishap at your ISP implied a bad DNS configuration which emulates the effect of DNS poisoning, redirecting your connection attempt to the wrong server;
  • Google does not know how to do SSL;
  • there is something fishy in your Pidgin configuration.

From here, connecting to port 443 on talk.google.com results in a server certificate which includes the name: subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=talk.google.com, which is correct.

Note that Google is known to play tricks with the DNS. From my home machine, talk.google.com is resolved to an alias to talk.l.google.com, which has IP 74.125.113.125. From another machine on another continent, talk.google.com is resolved to an alias to talk.l.google.com, which this time has IP 209.85.147.125. There is obviously some sort of worldwide load-balancing in action here.

Bottom-line: you cannot check "by yourself" whether a certificate is good or not, save perhaps by phoning the Google headquarters and having them spell out the certificate fingerprint (which they might agree to; they are rumoured to value such kind of humour). Actually, the message you get is a rather definite indication that you do not get the right certificate, so you'd better use the message as a symptom and investigate if you indeed connect to the right server. I suggest trying Wireshark to see what server Pidgin is actually contacting, and what happens at the SSL level.

Improve this answer
3
  • 1
    So, what you're saying is that Pidgin is effectively bugging users unnecessarily, since nothing really can be done with the information it displays?
    – Tomislav Nakic-Alfirevic
    Commented Jun 12, 2012 at 21:57
  • it's the client, gmail.com has some standard xmpp SRV DNS records pointing to talk.google.com, sometimes a client tries to match the ssl cert against the wrong domain (I've seen Gajim and Psi do this on google's cert before). And then there are some load balancing CNAMES added for a fun mix meaning more domains it can be matched against. Unfortunately this is an issue cause one can nolonger check cert validity.
    – ewanm89
    Commented Jun 24, 2012 at 10:14
  • That "worldwide load-balancing" you're talking about is Anycast
    – Shadok
    Commented Oct 23, 2012 at 16:42
7

How (and where) can I check if the new SSL certificate is valid?

  1. Save the certificate as a file (DER, Base-64, or PKCS #7).
  2. Read the Issuer for the certificate.
  3. Obtain the issuer's certificate.
    • The location of the issuer's certificate is typically specified by the "Authority Information Access" field.
  4. If the issuer's certificate is not a root CA then continue up the chain until you obtain all the certificate from the root CA to the certificate of interest.
  5. Starting at the certificate signed by the root CA check each certificate for validity period and correct subject naming
  6. Read the Signature Algorithm field for the has and encryption type used.
  7. Using the public key from the signing certificate decrypt the signature
  8. Calculate the hash value using the algorithm specified in the Signature Algorithm field of the certificate data up to but not including the signature.
  9. Compare the decrypted value to the calculated hash. If they match the signature is valid.
  10. Continue down the chain until you encounter a certificate which is invalid.
Improve this answer
4
  • I guess the problem with pidgin is that I don't have any of these fields.. Only BEGIN CERTIFICATE and END CERTIFICATE and what is in between of course. And I have the calculated hash value (SHA1).
    – tkit
    Commented Nov 4, 2011 at 20:05
  • @pootzko What does it display between BEGIN and END? Does it look like this: a1 02 b3 04 c5 5d 66 7e ?
    – this.josh
    Commented Nov 4, 2011 at 21:52
  • nope, it's compact. alphanumeric + a few special characters here and there... this is a short sample, part of one of the lines: "GVybmV0IEF1dGhvcml0eTAeFw0xMTEwMjUxOTIxNTd".
    – tkit
    Commented Nov 5, 2011 at 0:28
  • OpenSSL command line tools can convert the BEGIN/END CERTIFICATE blob into useful data... "OpenSSL x509 -inform PEM -text -in <text file>"
    – davenpcj
    Commented Aug 29, 2013 at 16:48
7

If you had Pidgin logging into two accounts, a Google Apps account and a Gmail account, then no worries, there's no certificate error. It's just a Pidgin bug that they've been ignoring for the past year.

Improve this answer
0

I just thought I'd throw out the solution to this problem. If you open the account setting for your gmail account and click on the advanced tab you'll probably see "Connect server:" set to talk.google.com. I'm not exactly sure what's going on (if this an old default or something), but getting rid of that solves the problem.

My guess from what I've seen in my Wireshark session is that it's connecting to talk.google.com, asking for the gmail.com certificate and then getting confused by the result (I'm not sure if it's getting the gmail cert and being confused because it connected to talk.google.com or if google is spitting up a bad cert because you're connecting to one server and asking for the cert from another server).

Improve this answer
1
  • I still get the SSL Certificate Verification dialog, even when setting Connect server: to talk.google.com. As you suggest, I think it is confused because it connected to talk.google.com but got the gmail cert.
    – Mark Booth
    Commented Mar 30, 2016 at 9:25
0

I resolved this by updating pidgin. 2.10.7 doesn't give me the certificate error that 2.7.11 did.

Though it was actually quite challenging to attempt to verify the certificate presented; I was never able to get any google service to give me a cert with the same thumbprint as the one pidgin was complaining about.

I don't think that's a MITM attack, just a lack of publication of the certs, and my own ability to figure out which server is ultimately answering the request.

But I wasn't comfortable accepting the error, so I hope the upgraded pidgin isn't doing that for me.

Improve this answer
-1

A different solution to the same issue: I simply had to delete a space character from the field:

Modify Account > Advanced > Connect server:

Not sure why the message only started showing now; I haven't changed the settings for ~ 2 years. Maybe this might help someone else.

Improve this answer
-1

Put the domain name (gmail.com) into a Firefox or Chrome with HTTPS (https://gmail.com) and check whether the URL bar/lock icon is green or not. Green means that the browser trusts the connection. After that check the certificate fingerprint in the browser and compare with the fingerprint from the Pidgin window.

I don't think that the domain name difference (gtalk.com vs. gmail.com) is a big issue, both are Google's domains.

Nowadays gmail.com redirects to accounts.google.com, so I use https://gmail.com/nosuchpage instead which only shows a 404 page without redirection.

Improve this answer
1
  • 1
    This doesn't address the OP's question.
    – Adi
    Commented Jul 23, 2014 at 17:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .