Re: Blocking Google Talk

["Mike Powell" <mikep () dri-eaz com>]

I'm the original poster of the "blocking google talk" question, so I
feel the need to weigh in on this.

> Bleh. Filtering out nameservers is one way of using a proxy to block
> traffic. You do run your own recursive resolvers anyway, right?
>
> Not running your own resolvers is a bad idea in the first place. [...]

> > It is a "band-aid" approach rather than a mature solution. [...]

We are running our own DNS internally, so although manually returning
localhost for talk.google.com will stop the Google Talk connections, I
also agree that it is a band-aid approach.

> > If Google can't provide a mature way of preventing traffic *1 what
does  > >that tell
> > you about the design of the program/protocol?
> Lets see, https for authentication, XMPP for communication? Rather
open
> standards, aren't these? [...]

It would be, if it actually happened that way. XMPP is supposed to use
port 5222. None of our users can get out on port 5222, and I see the
connections being successfully blocked in the logs. The Google Talk
client then goes on to make connections on ports 80 and 443 and happily
goes on about its business as if nothing was wrong. My belief is that
the Google Talk client identifies that port 5222 is blocked, and falls
back to transmitting data using HTTP-compliant communications in order
to get around the blocking that has been put in place. To me, this says
that someone planned for Google Talk to work around blocking, even if
XMPP on port 5222 was filtered. I call that deliberate subversion (and
it means that google lied on their google talk faq page about how the
client works). If someone out there has actually dissected the google
talk data on the wire, and my assumption that the client falls back to
http and/or http-over-ssl is incorrect, I would be happy to be set
straight. Note: we are not merely allowing ports 80 and 443 to pass,
they go through as proxied connections. This means that the Google Talk
connections are being made as proxy-aware http-compliant connections.

> This isn't a bandaid. Oh, and if you really want to stop the
> problem, why not just prevent the installation of the 
> software in the first place? [...]

Hey, what a great idea! FYI, I have installed Google Talk onto a machine
using an unprivileged domain user account. The google talk installer
will not let you continue with the install pointed into c:\Program
Files, but if you choose a directory that you as a user have full access
to (such as your own desktop), the installer will allow you to complete
and Google Talk will successfully start up. It won't add itself to the
Add/Remove Programs section if you are not a local admin, but it will
copy its files and allow the user to run it. Again, to me it sounds like
someone spent a lot of effort to make sure that non-admin users with
only limited internet connectivity (proxied http connections on ports 80
and 443) would be able to successfully run the google talk client.

Fortunately, I have been able to stop the google talk client from
logging in by blocking all URLs that start with http://talk.google.com
and https://talk.google.com. However, for those running firewalls that
are not http protocol-aware for filtering out specific URLs, it looks
like you are pretty much upriver sans propulsion. You can't just block
all communications to talk.google.com, because the addresses that
talk.google.com points to are the same addresses that www.google.com
points to. If you block talk.google.com by IP, you will also block
www.google.com.

Again, as I stated earlier, if someone has more time to dig into this
and can prove that Google Talk will not work with port 5222 blocked and
fails to install for a non-admin user, I would be happy to be corrected.
However, the information within this message is my understanding from
what I have been able to observe, and I haven't been very happy with
what I've observed.



Mike Powell
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards