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

From: Jan Tietze (jan.tietze_at_netheads.de)
Date: 03/25/05

  • Next message: Avishai Wool: "Re: [fw-wiz] Screening Router as a firewall"
    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


  • Next message: Avishai Wool: "Re: [fw-wiz] Screening Router as a firewall"

    Relevant Pages

    • [Full-disclosure] SSL VPNs and security
      ... In their most basic operating mode, SSL VPN systems simply act as a HTTPS ... enables the user to access any HTTP or HTTPS based Intranet applications; ... browser security model that relies on domain name separation for the ... all pages displayed through a Web VPN interface ...
      (Full-Disclosure)
    • SSL VPNs and security
      ... In their most basic operating mode, SSL VPN systems simply act as a HTTPS ... enables the user to access any HTTP or HTTPS based Intranet applications; ... browser security model that relies on domain name separation for the ... all pages displayed through a Web VPN interface ...
      (Bugtraq)
    • [Full-disclosure] Re: SSL VPNs and security
      ... SSL VPN is hardly a 'novelty' or 'recent' technology. ... The following observations are based on Cisco Web VPN (and your ... > enables the user to access any HTTP or HTTPS based Intranet applications; ... > purpose of restricting access to cookies and other objects. ...
      (Full-Disclosure)
    • Re: SSL VPNs and security
      ... SSL VPN is hardly a 'novelty' or 'recent' technology. ... The following observations are based on Cisco Web VPN (and your ... > enables the user to access any HTTP or HTTPS based Intranet applications; ... > purpose of restricting access to cookies and other objects. ...
      (Bugtraq)
    • RE: Remote Access for Home Computers
      ... connector and you are only connecting over SSL, ... no TRUE connection between the infected computer and your network. ... Juniper has something called Network Connect which is a virtual IPSEC ... access to specific resources via the SSL VPN, ...
      (Security-Basics)