[VPN] SSL "VPNs"

Richard Ginski rginski at co.pinellas.fl.us
Fri Feb 7 09:57:30 EST 2003


Here's a link to a case where an SSL VPN was deployed. When we spoke to Novell we learned that, not only can you access standard Intranet based applications using web servers (similar to what's been discussed here), but they also have capabilities to access user  folders and have a form of "terminal services" for interactive access such as Telnet sessions via an SSL-based system. This goes well beyond the initial impression of what SSL VPNs can do.

I guess I'm to blame regarding this thread (subject aka IPSEC and Clientless VPN). However, I just can't get comfortable with this level of access being provided without multiple OSI layers of security (such as application layer, system layer, and especially the network layer). I get nervous thinking about giving "carte blanche access" through a firewall to a protected network for this type of solution.

http://www.novell.com/success/hillsborough_county_fl.html

>>> Paul Cardon <paul at moquijo.com> 02/06/03 03:24PM >>>
Tina Bird wrote:

[SNIP]

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

[SNIP]

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

-paul

_______________________________________________
VPN mailing list
VPN at lists.shmoo.com 
http://lists.shmoo.com/mailman/listinfo/vpn




More information about the VPN mailing list