Re: SSL VPN vs. IPSec VPN

[Jan Tietze <jan.tietze () netheads de>]

Joe Mazzotti wrote:

> Greetings all,
>
>     I'd like to get some opinions on the pro's and con's of using an
> SSL VPN vs. using IPSec VPN for remote access to our corporate office.
> The idea is to eliminate 3rd party software and use a web based VPN
> solution to lower support cost.  Our options (aside from keeping our
>  
I have some experience bringing out SSL VPNs and have evaluated a number 
of products. One thing to keep in mind IMO is that there is no commonly 
established standard in SSL VPN yet - ie. what features to expect, what 
software it should work with. There are a number of different approaches 
to SSL VPN, each of which has its merits and downsides:

1. Completely replace traditional IPSec VPN - use different client 
software and TCP port 443 for transport/encapsulation of IP traffic and 
push regular network traffic over this connection. Add client software 
to allow transparent access to the network without application 
re-configuration; for instance, use a Layer Service Provider, network 
device driver or IPSec-like shim to provide the network connection.
2. Provide access to web applications only.
3. Provide access to "legacy" applications through "webification", ie. 
access to file shares using a web application, not a network connection.
4. Provide some application-specific support for network connections, 
ie. use local listeners on the loopback interface (set up by an ActiveX 
control or Java applet) and have applications connect through these, not 
tunneling network layer addresses, just connection payload.

(1) is much like traditional IPSec mobile user VPN, the difference being 
that this introduces a few potential problems for applications (when 
running TCP over TCP, the reaction to packet loss may be different from 
what you expect; potentially suboptimal behavior for realtime 
applications such as video and voice transmission, since TCP guarantees 
successful delivery and stream reassembly, which may introduce jitter to 
realtime traffic, where UDP would be preferred usually) and that it will 
usually work with corporate firewalls in case they allow HTTPS 
connections, even by proxy. I believe that once this is more common, 
more and more security people will require HTTPS inspection that breaks 
this kind of connectivity, since they disallow IPSec for a reason as 
well - you really don't want to have a full-blown network tunnel 
terminate on your network.

(2) The "pure web" approach is seldomly seen nowadays and of limited use 
obivously. However...

(3) ...for some applications it does make sense though, since you can 
extend the reach of some very common applications like file shares to 
other environments (Internet cafes, client and partner sites, workday 
extenders...), which is very handy at times. Some vendors include web 
applications in their products that allow some access to legacy apps 
through a web browser, eliminating the need for a network connection for 
these.

(4) This approach may work in corporate environments in the future even 
if the assumption I made in (1) was to become a reality, since this 
wouldn't create a network-layer connection to someone else's network.

For maximum flexibility, I would choose a solution that provides all of 
the above, so that it can be an IPSec replacement for mobile users on 
known machines (corporate laptops, homeworkers) for all applications as 
well as offer the typical benefits of SSL VPNs, ie. ubiquitious access 
using a web browser. Since this added flexibility introduces a security 
threat, an SSL VPN should check the integrity of a client and be able to 
provide graded access to applications. For instance, almost everyone 
should have access to web-based corporate email everywhere, but might 
only be allowed to download attachments to corporate laptops. With 
regard to client-side security features, SSL VPN solutions differ even 
more than they do in the way they provide the access technically; some 
can only allow or deny access, but not grade it, some won't do 
client-side security at all. Also, none of them are "clientless" when it 
comes to providing access to legacy applications obviously, and they 
support different ranges of client devices. You should look into these 
things when you consider a solution.

They also differ a lot in how they handle credentials (some vendors will 
allow you to use multiple repositories for initial authentication, like 
combining SecurID and RADIUS, and some will only allow one; some allow 
forwarding sign-on credentials to web applications, creating an SSO-like 
user experience), in the flexibility to customize and extend, and in the 
amount of application-specific knowledge (providing graded access to an 
application requires application support - recognizing the URLs used for 
downloading attachments in webmail, for instance).

My personal opinion would be that vendors who have added SSL-based VPN 
to traditional IPSec products have very little incentive to fully 
develop an SSL VPN that could compete with "pure" SSL VPNs. For 
site-to-site VPN, nothing beats IPSec of course, and there are few 
players left doing that over SSL, if any. For client-side security, I 
think that using APIs to query native applications like anti-virus or 
personal firewalls for their status and permit/deny access based on the 
result is not enough, and there should be a way to allow for graded 
access based on end-point properties. Given these features, SSL VPN can 
be used to safely replace IPSec mobile user VPN for the majority of 
users, giving them a lot more flexibility in daily work.

The value of SSL VPN also varies with your business case - I use it 
every day and wouldn't miss it, but I'm a consultant and I'm constantly 
in customer environments that restrict my network access. I can access 
e-mail and Citrix MetaFrame and a few other applications that make my 
life easier from all of the customer environments, and this has greatly 
enhanced my productivity while it has also increased security vs. 
directly providing access to webmail, Citrix through SG etc.

-- Jan
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards