Wednesday, July 18, 2007

Another reason to have X-GOOGLE-TOKEN?

In my previous post here about XMPP I had linked to a blog (here) that describes the X-GOOGLE-TOKEN mechanism of authentication. dJOEk asks a question "Why does Google use a proprietary authentication mechanism" and then goes on to make a point about how X-GOOGLE-TOKEN could be one of the first steps twoards a Single Sign On solution from Google. This point of view has received a lot of coverage with a several people commenting about the merits of this idea or its feasibility.

I have recently noticed another possible reason for X-GOOGLE-TOKEN to be made available and this is what I am putting forth here -
I had written in my blog that when I tried to sniff out the conversation between Google Talk and the server using Ethereal I found that it was using TLS and not X-GOOGLE-TOKEN and therefore all conversation was encrypted. Several people have since asked for ways around this but the whole point of TLS is to prevent such sniffing and decryption is practically (at least to me) impossible.

Since then my current company has installed an auditing software (I know :-() for compliance reasons and interestingly Google Talk is back to using X-GOOGLE-TOKEN. When using X-GOOGLE-TOKEN only the authentication part goes over TLS while the rest of the conversation does not which means that conversations are in plain text and can be intercepted, audited and archived. So, another possible reason for supporting a different authentication mechanism could be to be able to support auditing and monitoring software?


Peter Saint-Andre said...

As I understand it, X-GOOGLE-TOKEN is an authentication mechanism, which should mean it's a SASL mechanism. TLS is for channel encryption. You should upgrade the stream using STARTTLS, and then do authentication. So you could do both TLS and X-GOOGLE-TOKEN, and using X-GOOGLE-TOKEN doesn't necessarily mean that the channel is unencrypted. But maybe Google has done things a bit differently -- I'm speaking just from a pure XMPP perspective as author of the specs. ;-)

Sachin said...

Hey Peter,

You know a lot more about this than I would and this is just my conjecture and based on very little experience with XMPP and could therefore be horribly wrong!

What I was thinking was basically that using the X-GOOGLE-TOKEN mechanism, GoogleTalk can authenticate the user separately over TLS and retrieve a token which is used for SASL. Channel encryption using TLS is never started therefore allowing archiving and auditing software to work on unencrypted data. And you are very right - using X-GOOGLE-TOKEN does not necessarily mean that the channel is unencrypted. However, I notice that the auditing software does not send a starttls tag and supports only X-GOOGLE-TOKEN as the auth mechanism hence the theory that perhaps a reason for an alternative auth mechanism is to support unencrypted transmission with safe authenticaton?

Anonymous said...

I am making a site which i would like
to link with google am i gonna do that?
please help

Sachin said...

You will need to give more information for me to help you and also an email address.

marcuslira said...

I need to make a gtalk sniffer for my networks class in university.

When I try to capture the packets, they are encripted. I'm don't know how continue the work. Can you help me?

sorry for my bad english :)


Anonymous said...

Hi there,

I am looking for info on the X-Google-Token, but turns out that the blog is offline. I was wondering if you have saved that info, or if you have any other info on google's SSO.

Thanks a lot,


Sachin said...

@marcuslira: I have no idea how to get Google Talk to use X-GOOGLE-TOKEN but hopefully there is some information somewhere or the google forums might be useful. With TLS I don't think there is a practical way to sniff the contents - but I honestly don't know that for sure.

@Anonymous (2nd): I am sorry I don't have any information.