[fw-wiz] Re: SSL VPN vs. IPSec VPN

• Previous message: Brenno Hiemstra: "Re: [fw-wiz] Screening Router as a firewall"
• In reply to: Joe Mazzotti: "[fw-wiz] SSL VPN vs. IPSec VPN"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: firewall-wizards@honor.icsalabs.com
Date: Fri, 25 Mar 2005 18:45:15 +0100

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

• Previous message: Brenno Hiemstra: "Re: [fw-wiz] Screening Router as a firewall"
• In reply to: Joe Mazzotti: "[fw-wiz] SSL VPN vs. IPSec VPN"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]