Date: Thu, 06 Feb 2003 15:24:33 -0500
From: Paul Cardon <>
To: Tina Bird <>
Cc: "" <>
Subject: Re: [VPN] SSL "VPNs"

Tina Bird wrote:


> Details below for specific comments and questions on the three vendors I
> "reviewed." My requirements for the solution are: it must be able to
> support arbitrary custom database applications; it has to do granular
> user based access control (they all satisfied that requirement); it must
> contain the equivalent of "no split tunneling" or some other mechanism
> for defending against piggy back attacks (none of them did that).


> None of these vendors claims to address the split tunneling issue; none
> of them offers convincing evidence that they can route arbitrary
> IP-based traffic to an internal location, which I believe is a necessity
> in most environments.

I work at a Fortune 100 corporation in an industry where security is very important. We have had a lot of interest in SSL "VPNs" because of the perceived ability to deploy without a client. There are two significant issues that resulted in a decision to continue to use a traditional VPN client for thin client remote access.

The first was the "no split tunneling" capability. I don't know how this can be done without hooking into the IP stack and I don't know how that can be done with a browser, a Java applet, and a non-admin user account. SSL VPNs really can't enforce or ensure any kind of real client-side security. Sure they could check for certain other software and configuration but that only goes so far and only works in a non-hostile environment. If an SSL VPN is available for use to a large
user base it will be used at j-random web cafes, kiosks, conferences etc. It is too easy to use these things in highly hostile locations.

The second was that the VPN gateway would have fairly broad access to the WAN and I was not willing to depend on either Apache or IIS to secure that type of access. The SSL VPN products I have seen are built on one or the other. All of our Internet accessible web servers have additional security controls on the back side that restrict what they can communicate with on our internal network. To make VPN access a useful service we can't restrict the backend connectivity like we do with our web apps.

Now perhaps some companies who are using this technology understand these risks and have decided they are acceptable but I doubt there are money. When the vendors don't have an answer to either of those questions I would be certain that the majority of their customers aren't asking. The vendor says it's secure so it must be and many purchasers leave it at that.