Overview What is an SSL VPN

Document Sample
Overview What is an SSL VPN Powered By Docstoc
					SSL VPNs: Evaluation Criteria and Architecture
Joel Snyder/Opus One

This document represents my thinking about SSL VPN devices (and software), what
defines an SSL VPN device, and a set of evaluation criteria for SSL VPN. The intended
use of this document is as a base to differentiate different SSL VPN products, specifically
in making purchasing decisions. It is also my intention to use a subset of this document
as an evaluation methodology for product reviews of SSL VPN devices.

For the sake of simplicity, I am going to refer to SSL VPN products, software, and
services, as just “SSL VPN devices.” In the case where the SSL VPN really is an optional
application layer software piece (SSL Explorer is the only product I know that fits this
description right now, but there may be others), “SSL VPN device” may be a bit of

Document History
This document started in 2002 as a collection of thoughts on SSL and IPsec VPNs. It has
grown into a fairly lengthy discussion of how to compare different SSL VPN products.
This was the base document for a comprehensive review of SSL VPN products I did for
Network World in 2003. For the 2005 review, I have made extensive changes to reflect
changes both in the available products as well as the user requirements.

I am extremely grateful for the assistance provided by (in no particular order) AEP,
Array Networks, Aventail, Check Point, Citrix, F5, Fortinet, Juniper, and Permeo in
making the 2005 revision of this document.

Anyone reading or using this document after publication of Network World’s 2005
review should contact the author to be sure that they have the latest version.

What is an SSL VPN?
In order to evaluate SSL VPN products, it is important to understand what an SSL VPN
is, and, more importantly, where SSL VPNs came from.

It is clear that VPNs mean (or they should mean) more than “Layer 3 IP-based IPsec.” As
networks extend within and between corporations, different technologies can be
brought into play which solve the problem of securely extending network boundaries.
The best way to think of this is as a 2-dimensional space. Across one axis is the
“locality” of the problem: one department (“very local”), one division, one region, one
company, two sister companies, a joint venture, a consortium, or, at the far end of the
spectrum, hundreds or thousands of trading partners (“very distant”). Across the other
axis is the “specificity” of the problem: are we talking individual users (“very specific”),

Evaluation Criteria for SSL VPNs        August, 2005                            Page 1 of 17
encrypting end-to-end? Or is this a series of SOHO gateways? Or enormous sites
connected (“very broad”) together?

My point in describing this 2-space is to identify specific areas where IPsec VPNs are
generally unsatisfactory and where SSL VPNs are especially appropriate. By identifying
the problem we are trying to solve, we can then identify the key components of SSL
VPNs. The issue is that many non-IPsec VPN vendors are just not really sure what
market they are trying to approach and what problem they want to solve. While it is
always possible to jam a technology where it does not fit, the greatest leverage and
benefit comes when matching problem to solution.

In the 2-space I described, IPsec fails miserably at one end of the graph: very distant, and
very specific. For example, consider a bank which wishes to make private account
information available to its customer base over the Internet. Or, consider a sales order
tool where the salesman has little or no control over what access to the network he will
have from call to call. IPsec would be untenable in these situations. IPsec does poorly
here for a variety of reasons: the burden of policy management. The difficulty of
interoperability. Clumsiness of clients. All these, and more, suggest that alternate VPN
technologies might solve these problems better.

Actually, IPsec fails in multiple places in this 2-space, which is why the MPLS people
keep popping up, as well as the L2TP folks. But for the sake of keeping the argument
focused, let’s only look at the places where SSL excels and IPsec doesn’t. If you want
the whole picture on these technologies, draw out that graph yourself and the map will
be fairly obvious.

How, then, do we define the base requirements for a VPN technology, such as SSL-
based VPNs, to compete with IPsec? We must identify the crucial features which are
needed for SSL to meet the minimum level set by IPsec. Then, we must identify the
areas where SSL must go beyond IPsec to solve the problem of distant locations, but
user-by-user (specific) connections.

Before we go into requirements for SSL VPNs, it’s probably worth spending a little time
defining “what is an SSL VPN?” I don’t’ think that there’s going to be a huge
controversy over products which fit into this category, but I think that there are some
strong characteristics about SSL VPNs which make them different from Ipsec VPNs.

A working definition of an SSL VPN is: “An SSL VPN uses SSL and proxies to provide
authorized and secure access for end-users to HTTP, client/server, and file sharing
resource.” This implies that an SSL VPN has several defining characteristics. Without
these six characteristics, a product might offer useful functionality to some set of
enterprises, but is not going to be relevant to this document.

   1) Proxy access and protocol conversion: All SSL VPN products end up doing
      some kind of protocol conversion, if not on every data stream, at least on many
      data streams. For example, the widest application for SSL VPNs is going to be
      end users connection to the SSL VPN security gateway with HTTPS protocol,
      and the security gateway proxying access to resources it protects, such as http
      servers, SMB/FTP/NFS file servers, and even POP/IMAP mail servers. Thus,
      the SSL gateway both proxies access (the server sees a TCP/UDP connection to
      the security gateway, not to the end user) and provides protocol conversion
      (such as between FTP and HTTPS). The most trivial type of SSL VPN, an HTTPS

Evaluation Criteria for SSL VPNs       August, 2005                             Page 2 of 17
        to http (or even to HTTPS) conversion does fit into this definition, it probably
        represents the border case in defining SSL VPN technology.
   2)   Client-less access: At the very least, SSL VPNs must include client-less access
        (specifically, browser-based access), hopefully requiring neither Java nor
        Javascript for proper execution. Some vendors will want to extend their
        products to offer additional capabilities, such as port forwarding, either through
        an in-browser client (such as a Java application) or a separately downloadable
        client tool, but the core competence of the product must include client-less
   3)   Remote-access orientation: Although one could conceive of a site-to-site VPN
        over SSL protocol, this is not a natural use for this technology. SSL VPNs are
        designed for remote-access environments, end-user connecting to a corporate
        LAN and its resources. This implies more than “no site-to-site;” it also suggests
        that SSL VPNs need to be designed with simplicity and ease-of-use as primary
        architectural concerns. This ranges across the entire end-user experience, from
        the log-on screen and resource portal to broad-based browser and platform
   4)   Extranet support: SSL VPN products will likely be used in environments where
        the end-user has only a casual connection to the resources being protected, such
        as the oft-quoted “extranet environment.” This implies specific requirements on
        the proxies, including data stream modification (such as removal of internal DNS
        names and IP addresses).
   5)   Highly granular access control: SSL VPNs should have a very granular and
        specific access control, especially when compared to most IPsec designs. The full
        range of AAA (authentication, authorization, accounting) management controls
        should be available to the network manager. SSL VPNs should offer very
        precise control over who has access to which resources, when.
   6)   SSL Transport: As vendors change SSL VPNs to include client applications
        (much as IPsec VPNs use a client application), it would be possible to use other
        protocols than SSL for data transport. I do not regard this as a step in the right
        direction, since both the security characteristics and management control of the
        SSL protocol is well-known to security and network managers, and throwing
        other protocols into the mix begins to change the entire product category.

Using SSL for Network Extension
SSL VPN as a technology has become exciting to end users for (at least) two different
reasons. The first reason is to solve problems that really do not intersect with IPsec’s
“sweet spot,” specifically web-based application extension. The second reason is as a
replacement for IPsec: provision of network extension technology, but using SSL as the
underlying transport, rather than ESP as the transport.

The question of SSL VPN as network extension hits to the heart of the failure of most of
the IPsec remote access vendors to do a good job in creating and extending their
products. While the top three vendors, Check Point, Cisco, and Nortel, managed to
decimate the field of their competitors by being head-and-shoulders above the rest when
it came to IPsec remote access in 2001, they have failed to adopt many of the elegant
technologies now available to them to simplify the job of deployment of remote access

Evaluation Criteria for SSL VPNs       August, 2005                           Page 3 of 17
What this leaves us with is a large number of SSL VPN vendors, anxious to jump on the
bandwagon of SSL VPN, who are confusing what are essentially packaging issues with
real differences in the base technology. For example, most SSL VPN vendors have gone
far past IPsec VPN products by creating easy-to-install and easy-to-provision VPN
clients, by creating powerful web-based management tools for VPN managers, and by
working hard to tunnel and encapsulate their traffic in a way that is friendly to the most
unfriendly of broadband service provider.

In other words, if Cisco (for example) created a web-based provisioning system for their
VPN client, dramatically cleaned up the 3000-series web GUI, and offered the option of
tunneling IPsec over TCP port 443 through an HTTP proxy instead of over port 10000,
their IPsec product would become largely indistinguishable from many of the SSL VPN
network extension products. And from a marketing rhetoric point of view, it would be
entirely identical.

Many of the “benefits” of SSL VPN when used in a network extension environment are
completely orthogonal to the question of SSL or IPsec transport. Features such as end-
point security, gateway and client-based firewall, and layer 7 controls are being cited as
reasons to prefer SSL VPN, when, in fact, they are simply features in better products and
could be used in SSL or IPsec VPN.

The opposite has already happened: Juniper’s network extension client attempts to use
ESP data transport for traffic, if possible, leveraging the obvious performance benefits of
ESP over SSL-over-TCP. Aventail is extending their layer 7 proxy controls to control
layer 3 connections. Thus, forward-looking SSL VPN vendors are trying to incorporate
IPsec-ish technologies when it benefits their products, or apply SSL VPN givens to IPsec-
ish connections.

My conclusion here is that there is very little that realistically differentiates network
extension SSL VPN from IPsec VPN using a technology point of view, while there are
enormous differences between the two technologies in the various vendor
implementations---but that these differences will, over time, be quickly smoothed out
and further make network extension a blurred feature that can be included in a box
generically labeled “remote access gateway” whether using ESP or SSL transport.

What will differentiate these technologies is what SSL VPN can do that IPsec VPN
cannot do: browser-based extension of applications to users on all platforms, regardless
of operating system, browser version, or company affiliation.

A reader might ask after reading this long-winded discussion: “what’s the point, Joel?”
The point is that a product that only provides network extension, even over SSL
transport, is not an SSL VPN device---it is a competitor to an IPsec VPN device. Thus,
we are declining to include in this review products that do not offer core SSL VPN
technologies as listed in the previous section because they are not SSL VPN products, by
definition. In addition, we are not going to review pure IPsec products, for the same

However, we will be considering the capabilities and performance characteristics of
IPsec VPN as the “gold standard” that SSL VPN operating in network extension mode
must meet to be considered as credible network extension products.

Evaluation Criteria for SSL VPNs        August, 2005                            Page 4 of 17
Evaluating SSL VPN
The following list of items represents basic requirements for an SSL-based VPN device.
These form the evaluation criteria when selecting SSL-based VPN products. These are
not listed in order of importance, because each enterprise will have different areas that
are important. For example, some may not care about auditing, or about centralized
management, but may care about end-point security. Others may have exactly the
opposite ordering. In any evaluation, ordering and weighting of criteria is an important
first step.

1) Authentication Options and Authorization Support
   One of the absolutely critical features for any VPN product is the ability to
   authenticate users with a wide variety of technologies. Enterprises have never
   agreed on authentication technologies and the market is filled with commonly used
   alternatives. Any SSL-based product should support multiple user authentication
   methods (meaning that multiple methods may be in use at any one time), including
   at least the first 3 from the following list:

       a) Simple username/password from local database (for purposes of debugging
          and testing, as well as for special user exceptions)
       b) Simple username/password from a RADIUS server
       c) Simple username/password from an LDAP server
       d) Simple username/password from a Windows domain (could be done via
          RADIUS, but there are issues with the elegance of this solution when it comes
          to group attributes and authorization)
       e) SecurID, either directly to an ACE server or via RADIUS, but absolutely with
          support of “new PIN” and “next value” mode, in any case.
       f) Other one-time password technologies such as challenge/response and
       g) Digital certificates

   Because SSL-based VPN products are also web products, they will need to integrate
   into other enterprise web applications. We’ll look at this more specifically later, but
   this implies that the ability to accept single-sign-on or other authentication
   information from trusted sources, such as web access control portals, is also

   Each user authenticated via an external authentication server must be placed into
   one or more groups of users based on some information gathered from the external
   authentication server. For example, if LDAP is used, variables and group
   information need to be extracted from the LDAP directory to determine user
   authorization. In RADIUS authentication, less information is available, but what
   little information can be extracted from RADIUS needs to be available for grouping

   Although I believe that group and user information will need to come out of the
   authentication service (making it partially an authorization service), it is possible
   that some network managers will want to retrieve actual access control information
   from the authentication database (such as LDAP or RADIUS) as well. This is

Evaluation Criteria for SSL VPNs       August, 2005                            Page 5 of 17
   probably a fringe case, but is certainly one that should be considered in the

2) Fine-grained Access Control and Firewall
   Central to the idea of any SSLVPN is control over access. VPNs are not just about
   encrypting data between two sites; that’s a side-effect of the real goal, which is
   controlling access: giving access to specific resources to properly authenticated users,
   while restricting access to everyone else. SSL VPNs have even higher requirements
   for access control than IPsec VPNs, because they will often be used in Extranet
   environments where trading partners are not fully trusted. However, the need for
   fine-grained control is not restricted to extranets; it includes access controls for
   employees that extend beyond “this employee has access to that resource,” but “this
   employee has access from a particular desktop or laptop, when certain integrity
   controls are met.” It’s not a question of trusting the employee, but also trusting the
   environment the employee is in at the moment they want access. Thus, SSL-based
   products should have access control in several areas, including at least the first seven
   of the following:

       a) Source IP and Destination IP; Destination DNS
       b) Destination port
       c) Time-of-day; day of week; limits on date
       d) User name
       e) User group (e.g., OU information from a DN on a certificate or Windows
          Groups from the Windows SAM)
       f) User identifiers held (e.g., “User can dialup” bit in Windows SAM or Service-
          Type=Administrative via RADIUS)
       g) Application layer information (e.g., http GET versus PUT; URL data; file
          store versus file retrieval)
       h) Status of client integrity check
       i) Authentication method
       j) Client platform (i.e., browser type; Java-enabled; cookie-enabled)
       k) Strength of encryption

   The ability of an SSL VPN product to extend some or all of these controls across
   multiple access methods (traditional reverse proxy, port forwarding, and network
   extension) is an important differentiator between SSL VPN and IPsec VPN, because
   IPsec VPN traditionally is not as tightly controlled.

   Access control at higher levels, such as http URL filtering, is one area where the SSL
   product begins to cross product space and become a more general SSL proxy or
   front-end to web servers. This is a perfectly fine product niche, with a number of
   excellent alternatives (Netegrity, Tivoli, Novell, etc.), but it’s important to be careful
   in product design and to understand where the real focus of an SSL VPN device is.
   There are lots of ways to get distracted going down this path.

   Access control must be accompanied by a stronger security model than traditional
   packet filters. SSL VPNs need to apply these strong security controls to each of the
   access methods supported. Thus, for reverse proxying, one would expect protocol

Evaluation Criteria for SSL VPNs        August, 2005                              Page 6 of 17
     enforcement and validation in each supported protocol. For network extension, SSL
     VPN devices should provide stateful packet filters.

     Strong access controls in SSL VPN devices may go beyond explicit controls and be
     extended to implicit controls, such as those that might be provided by an intrusion
     prevention system integrated with the SSL VPN device.

3)      Management, High Availability, and Scalability
     SSL VPN management needs to be streamlined and appropriate for the technology.
     Because SSL VPN vendors have the benefit of watching both IPsec VPN and firewall
     products grow and mature in their management capabilities, it is naturally expected
     that SSL VPN devices will come “out of the gate” with mature and well-designed
     management systems.

     Over the past several years, SSL VPN vendors have worked to increase the
     capabilities of their systems, such as by adding end-point security and network
     extension. Their management systems should reflect a clean architecture that allows
     them to smoothly integrate these new features, rather than a series of ugly warts that
     were glued onto the management interface because there was no other way to get
     them in.

     Management is a large topic, but segregating it into the specific areas of
     configuration management, operations management and monitoring, and auditing,
     logging and reporting will help to break the problem down into manageable (no pun
     intended) chunks.

     Enterprises rarely have one of anything; they keep backups and redundant systems
     and do load sharing and hot spares and service multiple data centers in multiple
     locations. While element management (controlling each device as a separate security
     domain) is marginally acceptable in smaller installations, enterprises will insist on
     centralized management to keep costs and control within acceptable boundaries.

     Closely related to the idea of centralized management are the key needs of scalability
     and high availability. There are many different ways to provide both high-
     availability and scalability in web-based services such as SSL VPN, ranging from
     simply clustering boxes together to multi-LAN, multi-site, and multi-provider
     approaches. All of these are enabled by well-designed centralized management. As
     part of an evaluation of SSL VPN, the combination of centralized management and
     the capabilities of each system to both scale beyond the power of a single system and
     provide high-availability are important to evaluate and understand.

     The following criteria represent areas to be evaluated:

        a) How well does the product support centralized management of
        b) How well does the product support centralized operations of multiple
        c) What SNMP MIB information is available to assist in operations and

Evaluation Criteria for SSL VPNs        August, 2005                           Page 7 of 17
        d) How well does the product support aggregated logging, auditing, and
           reporting features? (Note that this is separate from just logging, auditing,
           and reporting, which are important enough to have their own section below)
        e) What paradigms does the product support for high availability, including
           single-site and multi-site?
        f) What paradigms does the product support for scalability, both within a site
           and across multiple sites?

     Note that features such as high availability and scalability are so often intertwined
     that they may need to be handled as a single criterion for evaluation, rather than as
     two separate criteria.

     The required parameters of centralized management are difficult to state, but it is
     easy to list a series of “nice-to-haves:”

        a) No requirement for a central management server; management service built
           into one or more devices
        b) No requirement for a specific management client; use web browser to
           manage the system
        c) Ability for multiple users to manage simultaneously
        d) Delegated management (e.g., allow some users to manage subsets of the
           entire network, such as who has access to a particular department’s web
        e) Partitioned management (e.g., allow some users to manage only certain
           functions, such as generate reports or view device status)
        f) Real-time operations management information (e.g., “who is logged on
           now?” or “what is the system load?”) along with real-time operations control
           (e.g., “log that person off now”)

     Most enterprises will have one or more network management consoles, ranging
     from full-fledged Tivoli or HP OpenView implementations across to WhatsUp
     management tools. It is unlikely that full management will be available from any of
     these external sources, but some provision for status information export via SNMP
     counters and SNMP traps from each device must be possible. This is non-centralized
     management: it should come from each device individually. Note that sending these
     traps and data may create a requirement for an IPsec tunnel-mode tunnel! (OK, just
     kidding, we don’t expect these devices to be that smart, although I am not sure why

4)      Auditing, logging, and accounting
     A well-thought-out strategy for auditing, logging, and accounting is important for
     long-term usefulness of any security product. This is one area where the diversity of
     implementation among existing products is particularly astonishing. At a minimum,
     an SSL VPN product should have the following:

        a) Auditing : every successful or unsuccessful user login and access needs to be
           audited via some logging mechanism; every management action needs to be
           audited; every system startup and shutdown needs to be audited.

Evaluation Criteria for SSL VPNs        August, 2005                            Page 8 of 17
       b) Accounting: summary statistics on user sessions need to be aggregated and
          held via either logging or RADIUS accounting. This would include values
          such as time connected, data transferred in/out, and other relevant counters.
       c) Logging: the recording of audit and accounting information needs to be
          managed in a versatile manner. Audit and log information need to be stored
          locally within some ring buffer, with flexible control if the buffer fills (e.g.,
          overwrite, system halt, email or FTP outbound). Local buffers need to be
          retrievable from remote systems via common mechanisms, such as TFTP or
          FTP. SYSLOG and/or SNMP need to be available as options for real-time
          logging and health-check information.

   Because one of the goals of SSL VPN products is authentication of end users, some
   sort of break-in detection and evasion is important. If the SSL VPN sits on a non-
   dedicated hardware platform (such as Windows or Unix), additional logging and
   break-in/intrusion detection subsystems may need to be added. This could be as
   simple as Tripwire or as complex as a full-fledged host intrusion detection system.
   However, if you think you need a full HIDS, you probably have done something
   wrong in designing the architecture of your product.

   In general, IPsec VPNs with a minimum of persistent storage (FLASH rather than
   hard drives) have done better in the marketplace than their spinning disk rivals
   because they create greater trust among network managers, both at the operating
   system hardening level and at the product reliability level. It is not a requirement
   that the SSL VPN device have no moving parts (even fans!), but it is certainly highly
   desirable to follow in the footsteps of what has worked for IPsec VPNs.

   Reporting will normally be handled via existing tools, such as HTTP usage logs
   (WWW/URL reporting and analysis using tools such as WebTrends) and RADIUS
   accounting (usage reporting and traditional accounting). An SSL VPN product
   should be able to generate relevant logs in both formats to facilitate integration into
   existing production reporting systems. That is, session information should be sent
   to RADIUS-style accounting databases, while individual URL information should go
   to HTTP usage logging in the normal industry-standard formats.

   Internal reporting tools that generate reports, summaries, and trends are nice as well,
   but it is critical to be able to export data. These tend to make better demo-ware than
   useful tools. Real-time (as events occur) and batch-mode data export (on demand or
   periodically) are both going to be interesting to enterprise network managers.
   Products which support all three (RT, batch-timed, batch-on-demand) would meet
   the needs of more enterprises.

5)  Wide-range of client systems, both operating system and
   One of the goals of an SSL VPN is to go where IPsec VPNs cannot. As a general rule,
   IPsec clients are particularly snippy about operating systems and even version
   information. SSL VPNs cannot be, because they must extend to a wide variety of
   environments. Any SSL VPN must accommodate the following in one way or

Evaluation Criteria for SSL VPNs       August, 2005                            Page 9 of 17
        a) Common enterprise and hobbyist browsers (IE, Firefox, Safari, Netscape,
        b) Common enterprise and hobbyist operating systems (Windows of various
           versions, Mac OS X, Linux using common X-based GUIs)
        c) Common mobile device platforms (Palm, Pocket PC/WinCE, Symbian)
        d) Unusual browser platforms (e.g., WebTV, kiosks, embedded systems)
        e) Lack of Javascript capability
        f) Lack of Java applet capability
        g) Lack of ActiveX capability
        h) Users who do not have administrative privileges on their own systems
        i) Smaller screen sizes
        j) Non-English environments
        k) Handicapped users without access to pointing devices
        l) Low bandwidth users and locations
        m) No problem working through NAT and NAPT environments

     In many cases, the underlying application will not be so forgiving, but it should be
     the application which is the gating function, not the SSL VPN gateway in front of it.

     Obviously, some non-http applications will require additional client capabilities
     (such as Java for a terminal emulator or port forwarder), but the needs of particular
     applications should not be used as excuses to constrain the entire product. For
     example, it is not reasonable to say that “we will need Javascript for Feature X, ergo
     we will assume that Javascript is a given,” even if Feature X is central to many uses
     of the product.

     In looking at device support, it is important to differentiate between specific support
     for devices by the SSL VPN device’s portal and additional features specifically
     related to retargeting content onto other devices. It is a requirement and expectation
     that the SSL VPN operate at the lowest common denominator of web client and
     operating system platform. It is an exciting and welcome extension for the SSL VPN
     to participate in the process of making content more usable in small screen and low
     bandwidth mobile devices. However, these features must be evaluated separately,
     since one is a given and the other is optional.

6)      Support beyond HTTP proxy
     SSL-based VPNs will operate most naturally against http and https servers, since the
     client used is a web browser. However, the ability to push other protocols through
     an SSL connection and to gateway other applications will differentiate these
     products from one another.

     I loosely group these capabilities into three categories:

        a) Protocol Translation
        b) Port Forwarding
        c) Network Extension

     Protocol Translation retains the browser-based interface of pure HTTP proxy, but
     either directly translates some enterprise protocol into a combination of HTTP and
     HTML, or delivers an enterprise application through a Java or ActiveX application

Evaluation Criteria for SSL VPNs         August, 2005                          Page 10 of 17
   operating within the browser. Examples of the first are very common in the form of
   file service applications (SMB/CIFS, NFS, FTP, and IPX) and occasionally email
   applications, essentially including a webmail client within the SSL VPN device itself.
   Examples of the second type of protocol translation, perhaps better called
   application delivery, are commonly terminal-oriented applications, such as
   Microsoft RDC (Terminal Services), Telnet, and SSH.

   In “pure” protocol translation, nothing other than a browser is required for access
   (although Javascript is commonly needed for the presented GUI); in application
   delivery, the browser must offer considerably greater facilities and thus there are
   often substantial interoperability issues across browsers and platforms.

   It is important to note that with protocol translation, the SSL VPN device is
   responsible for delivery of the information within the browser itself, without relying
   on client applications that might be pre-installed on the client system.

   Characteristics to evaluate when looking at protocol translation include:

       a) The number and type of actual protocols supported
       b) How access controls are applied to those protocols
       c) For application delivery, what interoperability and compatibility issues are

   Port Forwarding is half-way to true network extension, but requires a browser-
   present port forwarding listener, typically written in either Java or using ActiveX, to
   extend small numbers of client/server applications, such as an LDAP or email
   server. Although port forwarding has obvious end-user support issues, it has a
   number of desirable characteristics from the point of end-point security, since the
   hole through the SSL VPN device is much smaller than it would be in a network
   extension environment.

   Characteristics to evaluate when looking at port forwarding include:

       a) Interoperability of port forwarding listeners across platforms and browsers
       b) Ability of port forwarding to operate in a “no admin access” environment
       c) User-friendly aspects, such as automated launching, modification of the local
          “hosts” file, and automatic creation of port forwarding mappings for
          applications such as MS Exchange
       d) How access controls are applied to port forwarding

   Network Extension offers, essentially, the same attributes as traditional IPsec VPN
   remote access, although encapsulated in an SSL-over-TCP-port-443 data stream. The
   expectation of the end user is that SSL VPN network extension perform as well as
   and with the same power as IPsec VPN. Thus, in evaluating Network Extension
   over SSL, the following questions are key to understanding the client and comparing
   client services across devices:

       a) How is the client deployed, and how is the policy updated?
       b) Are normal client-side features such as split tunneling and local LAN access
       c) What interfaces does the client present to the operating system (i.e., shim,
          virtual adapter, PPP)?
       d) What measures does the client take to avoid TCP-over-TCP issues?

Evaluation Criteria for SSL VPNs      August, 2005                             Page 11 of 17
        e) What platform support is available in the client?
        f) How does the client operate in a “no admin access” environment?

     One additional area where some SSL VPN devices have brought non-HTTP proxy
     services is in native email protocol gateway, offering email protocols including
     SMTP-over-TLS, IMAP-over-TLS, and POP3-over-TLS through the SSL VPN device
     towards mail servers on the internal network. I believe that this feature will appeal
     to a limited set of end users, but its inclusion should be considered as a
     differentiating factor.

7)      End Point Security

     End Point Security (EPS) has become the hot story for SSL VPN and other network
     access environments in 2005. While Cisco and Microsoft fight out the EPS issues on
     corporate LANs, SSL VPN vendors are being forced to forge their own paths for
     remote access environments. This has created a highly fragmented and highly
     undesirable environment, with multiple overlapping and conflicting solutions. It is
     my fond hope that eventually the world of end point security will evolve into one
     where a unified solution can be built that works in both the corporate LAN and
     wireless as well as remote access environments. However, until that time comes (if it
     ever comes), SSL VPN devices may have some sort of ability to evaluate the integrity
     of connecting end points and modify access controls based on the results of those
     evaluations. Because not all SSL VPN environments will call for End Point Security,
     these are more important in network extension types of deployments than they are
     in HTTP reverse proxy deployments.

     End Point Security systems, where present, will have three parts: integrity checking,
     behavior changes based on check results, and data protective services.

     End Point Security starts with client integrity checking, a problematic at best
     operation. The client integrity check must operate:

        a)   Prior to end-user authentication (if desired by the network manager)
        b)   In environments where no administrative access is present
        c)   On browsers that may or may not have ActiveX or Java enabled
        d)   Differently depending on platform and browser capabilities

     While the range of integrity checking is very wide, some of the simple functions
     would include:

        a) Is a personal firewall running?
        b) What policy version is installed in the firewall? What is the software
        c) Is a virus scanner running?
        d) What policy version is installed in the virus scanner? What is the software
        e) Is in-memory virus scanning enabled?
        f) When was the last time a full disk scan was executed?

Evaluation Criteria for SSL VPNs        August, 2005                           Page 12 of 17
        g) Has a particular integrity application (presumably corporate-supplied) been
        h) What are the results of running this custom integrity application?
        i) What version and policy (of the integrity application) are installed?
        j) What processes are running? What IP ports are open?
        k) What are registry key values?
        l) Are certain files present on the hard drive? Or absent?
        m) Can the client system run certain applications, such as cache cleaners or
           virtual desktops?

     The SSL VPN device should also be able to talk to centralized firewall policy servers
     so that questions such as “what is the current policy version” are taken in real-time
     from the policy server rather than requiring the network manager to constantly
     update the SSL VPN management interface. To the extent possible, the SSL VPN
     device should cede responsibility for evaluating client integrity information to a
     policy server rather than evaluating it directly on the SSL VPN device.

     Once integrity checking is complete, the SSL VPN device must be able to classify the
     end user’s system into a profile and use that information to mediate access controls.
     While these changes on the basic access controls on resources are fairly
     straightforward, the SSL VPN device might take other actions based on the results of
     the integrity scan, such as refusing to paint the authorization screen (i.e., not letting
     the user even type their username/password, in case a keystroke logger is
     suspected) or redirecting the user to a remediation server.

     The third aspect of end point security is assisting in protecting data, both on and off
     the client. This can be done on the client, with personal firewalls, and on the SSL
     VPN device, by evaluating the content and intention of data passing through the SSL
     VPN. Many network managers are also charging the SSL VPN device with ensuring
     that sensitive data are not left on the client system. This means that the SSL VPN
     must provide some tool, such as a virtual desktop or cache cleaner, which helps the
     end user clear out cookies, cache data, saved passwords, URL logs, and any other
     information which might be re-used by the next person to touch the client. Similarly,
     some mechanism to restrict the ability to write to the local hard drive from the
     browser might well be included (where technically possible) to keep files from being
     downloaded and left on disk.

8)      User Workplace/Portal Functionality
     As noted above, SSL VPN products begin to overlap with more traditional web
     portal and access control products. It is important for an SSL VPN product to have
     clear lines which represent what it does and does not do in this area. Application
     managers need to understand what function the SSL VPN product provides, and
     where the architecture ends.

     Because an SSL VPN will likely be closely allied with a web browser on the client
     side, having control of different “start screens” or “user workplace” information for
     different kinds of users is important. These could be assigned based on user profile
     information and heavily customized static screens, or they could be built on-the-fly
     based on resources which are accessible to the user. In any case, some functionality
     to control what the user sees after they have been authenticated is valuable. At the

Evaluation Criteria for SSL VPNs         August, 2005                            Page 13 of 17
     same time, the ability to customize this at least at the user group level (and perhaps
     in a more sophisticated manner) will be expected by most network managers.

     Because SSL VPN devices appear to end users as if they were web application
     servers, they will have high expectations for their experience when using the web
     portal. They will likely expect the appearance and behavior of the portal to closely
     mimic other enterprise web applications they are used to using. SSL VPN vendors
     may choose to provide multiple levels of support for this type of customization. For
     example, some basic customization (such as logos, page appearance, etc.) should be
     controlled from the normal administrative user interface. More advanced
     customization, such as complete replacement of the portal interface, might require
     professional services or other special assistance. However, both these options
     should be available. Finally, SSL VPN devices should have the ability to
     immediately redirect users to a corporate portal, instead of an on-device portal, if
     desired. The extent to which these customizations can be accomplished at the user
     and group level will help to distinguish SSL VPN devices.

     Integration with existing portal products which support single sign-on is also going
     to be expected, although the enormous number and breadth of these products is
     staggering. The integration has to go both ways, as well. Single sign-on (SSO)
     information entered into the SSL VPN product should be able to be passed securely
     to the web portal/access control tool transparently to the user. SSO data from the
     web portal also should be usable by an SSL VPN device, so that the user does not
     have to re-authenticate. I understand that this is harder to do than it sounds, and
     many portal vendors may not have the API or interest in cooperation. However, a
     sound SSL VPN device should have sufficient architectural stability that this
     integration is possible.

     A full-fledged and highly-functional SSL VPN will include a full spectrum of
     application and portal integration, ranging from the simplest “single URL” access to
     enterprise resources, through a “mini-portal” presented by the SSL VPN security
     gateway, up to complete integration with an existing corporate portal so that end
     users see the same view of the world whether they’re on-net or coming in via a
     remote access VPN.

     Obviously, evaluating support in this area will be very difficult.

9)      High performance and Highly transparent
     In the category of “God and Mother” attributes, performance and transparency are
     given more lip service than attention. Nevertheless, the question of system
     performance will always dog SSL-based VPNs because of the high rate of security
     session creation, user authentication, and authorization lookups. SSL systems will
     be even more pressed than traditional IPsec systems, because of the high stress
     which an application-layer proxy and SSL itself puts on the system.

     It is difficult to put a requirement on performance, except to say that any SSL VPN
     device needs to have some audited performance statistics which will help the
     network manager predict correct device behavior in a variety of environments.
     Metrics which should be collected and reported (and verified by independent
     testing) include:

Evaluation Criteria for SSL VPNs        August, 2005                           Page 14 of 17
       a) Number of SSL session establishments per second
       b) Number of SSL session establishments with certificate-based authentication
          per second
       c) Maximum number of simultaneous SSL sessions and user sessions with
          acceptable system latency
       d) Number of application (within SSL) session establishments per second
       e) Encryption throughput using the highest security encryption and
          authentication algorithms (typically 3DES and SHA-1) supported (so-called
          “zero-loss” throughput, where packets lost is less than 0.01%), reported
          separately for network extension, port forwarding (if applicable), and HTTP
       f) HTTP rewriting throughput of complex web pages (such as those including
          Javascript or other scripting and programming language constructs)

   Another desirable, yet unmeasurable, metric is transparency. While end users will
   be aware of an authentication step, they won’t necessarily need to know what is
   happening when they are connected through the SSL VPN tool. This implies that
   careful thinking should go into configurations which allow the user to be both inside
   and outside the SSL VPN device without changing settings on their local system, and
   to handling the server-side authentication of SSL sessions.

   Other issues of transparency include the proper application-layer proxying of http
   traffic, such as internally embedded URLs (and other content) with IP addresses,
   DNS information, ActiveX, Java byte code, Javascript, Flash, and other data which
   may have different semantics and access control rules depending on whether the
   user is inside or outside the SSL VPN device. In this context, the word “proper” has
   two meanings: one is that the proxying enables proper operation of applications so
   that nothing is broken, and the other is that the proxying is secure and does not
   expose internal information (such as IP addresses, DNS information, and even
   possibly URLs) to external users. Obviously, this could be fairly difficult to
   configure and control.

10)    Control of Security Parameters
   Generally, SSL application users have not been overly concerned with the actual
   security parameters of their connection. While this may be reasonable for the very
   short-lived connections and fairly sloppy security requirements of a web form, it
   doesn’t suffice for corporate access. Any SSL-based product should have granular
   control of the SSL parameters used, including:

       a) Ability to require a certain level of encryption (key length and algorithm)
       b) Ability to require presence of a message authentication algorithm
       c) Ability to require Diffie-Hellman (or other two-party) key generation for
          session keys
       d) Ability to limit lifetime of a connection in time and octets

11)    Very Large Enterprise (and Service Provider) Features

Evaluation Criteria for SSL VPNs      August, 2005                          Page 15 of 17
   Until this point, basic SSL VPN requirements have been couched in the vocabulary
   of enterprises. However, larger enterprises and, to some extent, service providers,
   can make even greater demands on these products. Partitioned and delegated
   management may need to be an order of magnitude more complex to support the
   requirements of a service provider. For example, a normal enterprise may be willing
   to allow delegated managers to see where they are in a hierarchy, but not see other
   branches; a service provider or huge enterprise with extranet applications may want
   to have delegated management users completely partitioned from all other
   subgroups. (From the point of view of these products, large enterprises and service
   providers have nearly identical requirements and can be almost considered in the
   same breath.)

   Large enterprises may also have need for an application programming interface
   (API) which can be used to more tightly link non-web applications to the feature and
   function set of the SSL VPN security gateway. A “toolkit” for application developers
   will become more and more important as the size of enterprise implementing the
   product grows.

   Other enterprise and service provider features an SSL VPN product might include

       a) command-language ability to modify configuration outside of the GUI
       b) quality of service controls and guarantees on different resources or users or
          management domains
       c) integration with OSS tools for configuration and control
       d) ability to co-exist with other security applications on the same platform, such
          as a firewall
       e) integrated IPsec VPN functionality for management, logging, accounting,
          and reporting purposes
       f) tamper-proof/tamper-evident hardware with software alerting; control of
          direction of management (i.e., ability to disable console port, video display,
          management from inside, management from outside)
       g) disaster recovery procedures for backup of configuration and quick
          restoration (such as on externally accessible FLASH); other operations
          procedures more clearly laid out for backup, restore, deployment
       h) hardware security of keying material
       i) support for multiple languages in management and end-user interface

12)    Speed and Simplicity to Full-Scale Production
   SSL VPNs are going to have their “sweet spot” for enterprises in replacing what has
   been either dysfunctional or insufficiently flexible IPsec products. This means that
   enterprise network managers will have little patience for products which are difficult
   to install or integrate with their existing networks. SSL product vendors need to
   ensure that they provide:

       a) High-quality documentation, both in the “quick start” and “reference” areas
       b) Appliance-style installation, requiring little more than a power-on and
          designation of appropriate IP addresses

Evaluation Criteria for SSL VPNs      August, 2005                          Page 16 of 17
       c) Transparent implementation, not requiring network reconfiguration or
          topology changes
       d) Flexible and easy-to-configure integration with external directories/servers
          (RADIUS and LDAP, primarily) for authentication and authorization
       e) Support for end-user desktops in a wide variety of environments

   Some of these requirements overlap those above, but it’s the orientation here that is
   clear: making deployment easy for the network manager. SSL VPNs will be held to a
   higher standard than IPsec VPNs.

Evaluation Criteria for SSL VPNs      August, 2005                         Page 17 of 17

Shared By: