Re: [fw-wiz] Blocking Google Talk

How about blocking the program execution with domain group policies? This
takes subversion back to a conscious decision by the person installing the
application to go around the restrictions you've put in place.

Jon Czerwinski

-----Original Message-----
From: firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike
Sent: Tuesday, June 20, 2006 2:04 PM
To: firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [fw-wiz] Blocking Google Talk

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 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
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 and 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, because the addresses that points to are
the same addresses that points to. If you block by IP, you will also block

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

Mike Powell
firewall-wizards mailing list

firewall-wizards mailing list

Relevant Pages

  • Re: problem with file_get_contents
    ... No one wants to access Google on port 8000 and there are no requests from Google that are getting blocked. ... Outbound port blocking is commonly done by companies who care about their systems. ... that starbucks coffee is very expensive :-) ...
  • Re: [fw-wiz] Blocking Google Talk
    ... None of our users can get out on port 5222, ... connections being successfully blocked in the logs. ... Google talk falls through to 443/tcp if you block port 5222. ... to, the installer will allow you to complete ...
  • Re: [fw-wiz] Blocking Google Talk
    ... I'm the original poster of the "blocking google talk" question, ... None of our users can get out on port 5222, ... connections being successfully blocked in the logs. ...
  • help: using as SMART_HOST
    ... with my Google gmail address. ... is, using port 995. ... Retrieving mail is not the problem since my Google searches ... client, I believe the term is) to send my mail to Google's ...
  • Re: Can we move and leave no forwarding address?
    ... you should try using "real" Usenet access where you have a killfile and message processing rules to help filter out this crap. ... but it's better than having to repeatedly see these spam posts on Google. ... One really nice thing about Motzarella is that they also support using IP port 80. ... Using a traditional "NNTP" newsreader gives you greater control over filtering, sorting, and flagging messages. ...