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