syserr.com

I recently decided to place a block at our content filtering system for logmein.com and gotomypc.com.  Things were fine for a few months, with only a spattering of users complaining that they could no longer access their work computers from home.  This is exactly the reason I placed the block.  More recently, however, a few users, including the CIO, have come to me with some business case scenarios that have called for me to do some re-thinking.

Let’s think for a moment how LogMeIn.com works.  A host has a client installed and this client opens up an HTTPS session (or “tunnel”, if you will) that periodically sends polling keepalive packets, just to let the logmein servers know that it is alive.  These keepalive packets are sent to the cloud.  When a user logs into their logmein account, they see the machine they registered and can connect to it.  When a connection is made, the logmein servers simply proxy the connection through the already established HTTPS session.

|Host| — |Enterprise Firewall| — [INTERNET] — |LogMeIn.com| — [INTERNET] — |Firewall| — |Client|

As shown in this diagram, the Host is only connected to the Client via a SSL session that is established through a proxy server.  For Government and very secure infrastructures, this is a BAD IDEA.  It doesn’t matter how smart a workstation administrator thinks they are, and it doesn’t matter how often they say, “but it’s a secure connection”, it is not a MANAGED connection from an enterprise standpoint.  Because most firewalls allow all SSL port 443 sessions outbound (HTTP over SSL), they will most certainly also allow logmein.com to connect to it’s gateway in the cloud.

We have a policy that is a gray area on this issue.  VPN tunnels are prohibited from terminating outside of the enterprise firewalls unless they are managed by our organization.  Although this isn’t technically called a VPN tunnel, it IS treated like one, with data flowing over a SSL tunnel.  With this policy in place, the websites were simply blocked at the content filtering system.

Herein lies the problem.  When vendors come into our environment, sometimes they use these services to get to their OWN demo machines.  This means the service is running inside their network and they cannot get to it because we have blocked the URLs explicitly.

And this is where the work comes in.  I must somehow block the service from being run inside the infrastructure (even on servers/workstations that we don’t directly manage), but still allow access to the website itself, so vendors can do their demos.  The risk I’m taking is that users can then install it at home and work on their home PCs while at work.  There are policies prohibiting use of the network for non-business matters, but this is an exception that the enterprise will just have to make.