Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

6 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
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 Jun 12 '12 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 Jun 24 '12 at 10:14
    
That "worldwide load-balancing" you're talking about is Anycast –  Shadok Oct 23 '12 at 16:42
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
    
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). –  pootzko Nov 4 '11 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 Nov 4 '11 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". –  pootzko Nov 5 '11 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 Aug 29 '13 at 16:48
add comment

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).

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.