On 20/06/06 11:04 -0700, Mike Powell wrote:

> 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

According to TFM on talk.google.com


Google talk falls through to 443/tcp if you block port 5222. Google talk
is also proxy (and proxy authentication) aware, so merely putting those
up as requirements will not help. Blocking it in the proxy (as you have
done) will work though.

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

Interesting. I don't have a MS Windows machine around here to test, so I
can't confirm that behaviour. Someone else should be able to though.

Devdas Bhagat
firewall-wizards mailing list