Vous êtes sur la page 1sur 10

SSL VPN Security

Secure Remote Access from Any Web Browser



Joseph Steinberg
Director of Technical Services, Whale Communications

May 16, 2003



Abstract:

SSL VPN is an exciting new technology that allows remote access to applications and files from
standard web browsers. Because they require no client-side software other than a web browser,
SSL VPNs offers great convenience, and promise to provide a much lower Total Cost of
Ownership than IPSEC VPNs. Yet, at the same time, this novel technology presents new
challenges in the realm of security. This article explains how to deploy an SSL VPN securely
exploring both the security issues and proposed solutions.


Introduction

SSL VPN technology allows users to remotely access important enterprise applications, systems,
and files from standard web browsers. Technically speaking, SSL VPNs are composed of
specialized reverse-proxy servers
1
that have been enhanced to provide users with secure remote
access to internal resources. The added functionality includes subsystems to handle
authentication, user experience such as navigation between applications, security, and the
translation of internal applications to Internet-accessible formats.

SSL VPN technology promises to improve both employee productivity and convenience by
freeing users from having to carry laptops when traveling, and allowing access from any
Internet-enabled computer. The technology also offers tremendous cost savings when compared
to classic IPSEC VPNs since it does not require purchasing or maintaining remote client
machines. Users also benefit, as they gain the convenience of being able to access corporate
resources from any computer that they wish to use.

However, as is often the case with innovative technologies, SSL VPN presents some new
challenges when it comes to security. SSL VPN security concerns fall into two categories: those
created by allowing access into the internal network (server-side issues), and those stemming the
fact that SSL VPNs must allow access from all browsers (browser-side issues) including those
not under organizational control.

1
In the context of this article, a reverse-proxy server is a computer that sits between a web server and its users and
controls communications between the two. It intercepts all requests to the web server, and, before relaying them to
the server, may enforce security. It may also improve performance though the use of caching.
SSL VPN Security Joseph Steinberg May 16, 2003

Page 2

Diagram of typical SSL VPN Architecture

Server-Side Security Issues

The significant server-side security risks that must be addressed when implementing an SSL
VPN are:

! Firewall ports must be opened. For communication to take place between the user and
the SSL VPN, and from the SSL VPN to the internal systems it publishes to the outside
world, TCP/IP communications must occur. Typically this involves opening ports (ports
443 and 80) from the Internet into an organizations DMZ, and from the DMZ to selected
systems in the back-office (many ports). Besides violating the corporate security policies
of most security-conscious organizations, opening such ports creates a serious security
risk to the enterprise. Hackers can potentially exploit the open ports to enter into an
organization.

! Application-level vulnerabilities Most SSL VPNs utilize web servers as part of their
underlying architecture. As such, any vulnerabilities in the underlying web servers (or
anywhere else within the SSL VPN software) may lead to a serious security breach. Even
hardening an SSL VPN appliance may not adequately address this problem; hardening is
never perfect, and even hardened SSL VPN platforms have been found to suffer from
vulnerabilities. Also, vulnerabilities that may be present in an appliances underlying
operating-system kernel can completely undermine its security. (Such a risk is not
theoretical; a recent hacking contest was won through the exploitation of exactly such a
vulnerability.) Worse yet, even if the SSL VPN appliance itself remains secure, because it
proxies requests to internal servers, vulnerabilities in internal systems may be exploited
by sending exploits to the SSL VPN server which will then send them to the back-end
servers.

! Authentication It is critical to ensure that users are who they claim to be especially
when you have no control over the computers from which users access the SSL VPN, and
cannot rely on the IP number of the users computer (or any other related information) for
any clue as to the users identity.

SSL VPN Security Joseph Steinberg May 16, 2003

Page 3
! Encryption Proper encryption is essential any time confidential information is
transmitted across the Internet. Data that is not properly encrypted can be read or even
saved for later viewing by any system it passes through.

To address these issues the following actions are recommended:

! Close firewall ports Air Gap is a secure architecture that allows the communication
necessary for SSL VPN access without the need to open firewall ports. It isolates the
Internet from internal systems and allows only application-level data to be transferred
between them through a solid-state memory bank; in essence, it is the ultimate hardened
platform. As Air Gap technology is discussed in numerous articles including some on the
SANS website, I will not discuss the details here. For more information please see the
pertinent articles listed in the Sources section below.

An alternative to Air Gap that is often proposed is to open firewall ports and allow access
from the Internet to a single machine a thoroughly hardened reverse proxy serving as an
application gateway, which would transmit requests to the SSL VPN. Deploying such an
architecture, however, is not only more complicated than implementing an Air Gap, it can
also be less secure. Firewall ports remain open, and, in the case of a breach, the proxy can
become a host used to stage attacks against the SSL VPN or even against internal
systems. Also, hardening is subject to failure even the most hardened application may
be vulnerable to compromise if the underlying operating system suffers from any
vulnerabilities and it is impossible to know if any vulnerabilities not known at the time
of an SSL VPN deployment will later be discovered in any particular operating system.

! Filter to prevent the exploitation of application-level vulnerabilities Filtering all
messages that are sent to the SSL VPN helps ensure that rogue requests do not
compromise the SSL VPN or the systems behind it. By utilizing positive-logic filtering
that is, an engine that allows only messages belonging to a set of known valid requests to
reach internal servers and rejects all others you can mitigate against even vulnerabilities
as of yet unknown. There are numerous filtering products on the market today, and
numerous articles are available about application-level filtering, so I will not dedicate
more real estate to this topic. Again, please see the Sources section at the end of this
paper for more information.

! Use strong authentication A sensible recommendation is that strong two-factor
authentication (such as one-time passwords, RSA SecurID, etc.) be used whenever an
SSL VPN is implemented. In the case of SSL VPNs, strong authentication is even more
essential than with IPSEC VPNs, as SSL VPNs will often be used in locations where
unknown parties can see a user enter his credentials.
2


2
Of course, it is possible that a keystroke and screen logger could be installed on a public or borrowed computer, or
that a one-time password mechanism may be compromised through cryptographic reverse-engineering. The
likelihood of such scenarios presenting a real-life threat, however, is far smaller than the risk of users gaining
unauthorized access when strong authentication is not used. Additionally, similar threats are present even when
using computers in ones office or an IPSEC VPN someone could be using a hidden video camera with a
telescopic lens to record user sessions, watch keystrokes, etc. The techniques described for securing an SSL VPN in
SSL VPN Security Joseph Steinberg May 16, 2003

Page 4

! Use SSL Encryption As should be obvious, make sure that SSL encryption is turned
on when deploying your SSL VPN youd be surprised, but some organizations neglect
to do this! Also, 128-bit is the de-facto SSL standard; weaker encryption is inappropriate
for usage when confidential data will be transmitted across the Internet.

Browser-Side SSL VPN Concerns

Until now we have discussed server-side security issues. But, there are also serious risks in
offering access from machines not known to be safe including:

! Sensitive data may remain on a public computer after a user completes his session.
A common example of this problem might be a user at an Internet kiosk who accesses his
email and opens a sensitive Word-document attachment, thereby creating a temporary file
containing the contents of the sensitive document on the Internet kiosk where any
subsequent kiosk user can access it. Problems of sensitive data are even more complex
sensitive data is cached not only in temporary files created by the opening of
attachments during user sessions, but also in:
! Other browser cache entries created during the user sessions
! URL entries memorized for AutoComplete
! Form-field contents memorized for AutoComplete
! Temporary files created by the downloading of files or any other mechanism during
user sessions
! Cookies generated during user sessions
! Any history information created during user sessions
! Any user credentials memorized by the browser during user sessions

! User credentials may remain on public computers after users log off. A user at an
Internet kiosk may log off, but a curious subsequent user may be able to re-instate the
original users session (even without knowing a valid password). This is possible because
many applications reply on HTTP Basic Authentication; HTTP Basic Authentication
caches credentials at the browser after a users initial login so that he is not prompted for
credentials every time he requests web pages. Unfortunately, logging out of an SSL VPN
often does not clear these credentials from the browsers cache, and, as a result, curious
or mischievous parties can potentially re-activate prior users sessions without
authenticating.

! Users may neglect to logout. Some users may close web browser windows instead of
logging out, others may browse to another web site after accessing back-end resources
and forget that their SSL VPN session is still live. Others may simply neglect to log out
and abandon the computer altogether. In any case, an organization cannot rely on every
individual user to log out.


this article are intended to address the threats most businesses would consider rational and significant, they are not
intended to address the concerns that may be considered in a top-secret military environment or the like.
SSL VPN Security Joseph Steinberg May 16, 2003

Page 5
! Worms and viruses present on home computers or borrowed machines may be
transferred to the corporate internal network via tunnels created by the SSL VPN.
This is especially true because users often access SSL VPNs from their home computers
which may be shared with other members of their families who download virus-
infected games from the Internet. Worms downloaded by a teenager using a file-
swapping system may utilize the SSL VPN to tunnel into the corporate internal network.
While anti-virus software may help protect against the spread of worms when installed on
computers under organizational control, such technology cannot be relied on to be
present on borrowed computers, home machines, or Internet kiosks.

! Internal networking information may be leaked. Because internal applications may
contain references to internal systems not DNS-listed to the world or to IP numbers valid
only on the internal LAN (e.g., NAT addresses part of the subnet 192.168.*.*), SSL
VPNs must convert all references to internal servers within internal applications to
Internet-accessible formats. The technology used to perform such a conversion is known
as Host Address Translation or HAT. However, implementations of HAT vary from
product to product, with significant differences in effectiveness, performance, and
security. One of the serious security risks of a HAT engine is that if improperly
implemented, it may disclose information about internal architecture for example, by
passing the names of internal systems and the ports on which they listen as a parameter
viewable by anyone accessing the SSL VPN (or by any subsequent user if such data
remains in the browsers history).


Diagram of Secure SSL VPN Architecture Described Below

For a safe deployment of an SSL VPN solution all of the aforementioned problems must be
addressed. My recommendation is to implement the following technologies:

! Implement a virtual shredder as part of the SSL VPN Virtual shredder technology,
often implemented as a Java or Active/X download, serves two functions:
o It erases from access devices all forms of temporary files, browser cache,
downloaded files and pages, cookies, history information, user credentials, and
other sensitive information possibly recorded by a web browser during an SSL
VPN session.
SSL VPN Security Joseph Steinberg May 16, 2003

Page 6
o If enforces security policies in cases where it cannot run. For example, an Internet
kiosk may prevent executables (such as a virtual shredder) from being
downloaded. Similarly, if the user is borrowing the computer from which he is
accessing the SSL VPN, he may wish to obey rules of etiquette and not download
programs. Yet it is precisely kiosks and borrowed computers that pose the greatest
risk in terms of leaking sensitive information to unauthorized parties. As such, an
SSL VPN must be equipped to adjust and address such situations appropriately
by allowing the maximum functionality without creating a security risk. For
example, if temporary files cannot be eliminated by a virtual shredder, an SSL
VPN might not allow email attachments to be downloaded. However, even in
situations where security mandates that attachments not be viewable, the SSL
VPN should still allow access to basic email messages delivering as much
functionality as is safe to offer.

One important note: a virtual shredder will be unable to completely protect against data
leaking due to user error. If a user sends an email containing a sensitive document to an
incorrect email address, leaves a printed list of one-time passwords at an Internet kiosk,
or saves sensitive files to the local hard drive on a borrowed computer and neglects to
remove them, data may leak. Of course, similar risks apply any time a user accesses any
system connected to the Internet regardless of whether he is in the office, using an
IPSEC VPN, or using an SSL VPN. Also, it is important to realize that people typically
utilize public computers for reading email, rather than for serious editing of documents or
performing long tasks. That, coupled with the fact that most users are unaware that
opening email attachments creates temporary files that remain even after the attached
document is closed, means that the risk of a user unintentionally abandoning a temporary
file created through the opening of an email attachment is far greater than that of a user
abandoning files he intentionally saved to the kiosk hard drive.

! Do not use HTTP Basic Authentication Use form-based authentication to the SSL
VPN, and make sure the SSL VPN system can overlay such authentication whenever the
internal applications utilize HTTP Basic Authentication. The SSL VPN should respond to
HTTP Basic Authentication requests from internal servers, so that no HTTP Basic
Authentication request (i.e., signal 401) ever reaches the browser.

! Use Non-Intrusive Timeouts Timeouts must be implemented to ensure that sessions
do not remain live indefinitely if users neglect to log off. Simple timeouts, however, may
cause legitimate users to lose work when typing long email messages or completing long
web-forms, since the SSL VPN and internal servers do not detect activity performed
solely on the browser. Non-intrusive timeout systems provide the user with a warning
message a minute or two before the timeout will actually occur and allow him to
respond and preserve his session (usually by clicking Extend Session on a popup
window). Abandoned sessions are timed out, and legitimate users are not inconvenienced.
Additionally, to address the situation in which a user abandons a public computer without
logging off and a mischievous or curious party approaches the machine before a session
timeout has occurred, it is recommended that you configure your SSL VPN to force users
to re-authenticate periodically regardless of user activity.
SSL VPN Security Joseph Steinberg May 16, 2003

Page 7

One more note about timeouts it is important to ensure that the SSL VPN can
distinguish between user activity and automated browser requests. A growing number of
software packages use an automatic refresh a request that is automatically sent from
the browser to the server every so often to keep data current on the browser. (For
example, Microsoft Outlook Web Access for Exchange uses an automatic refresh to keep
current the list of newly received email in a users Inbox.) If an SSL VPN does not
distinguish between requests sent by users and those automatically sent by the browser, it
will never detect an abandoned session, and it will continue to see user activity forever.
Abandoned sessions waste user licenses, and, of course, pose a major threat to security.

! Application-level filtering In much the same fashion that using an application-level
filter will prevent hackers from attacking back-end systems, it will also prevent worms
and viruses from doing the same. Viruses and worms utilize inappropriate requests to
compromise and hijack their victims; application-level filtering prevents any harmful
requests from reaching machines that may otherwise fall prey to application-level attacks.

! Encrypt all references to internal resources so the SSL VPN does not leak internal
information It is recommended that you configure your SSL VPN so that whenever it
communicates with users, it encrypts host names, server IP addresses, and any other
information about the internal infrastructure. Disclosing data about the internal
infrastructure is not necessary for an SSL VPN to function, and doing so poses a
significant security problem, as it arms hackers with information that may help them
attack your network.

Some SSL VPNs offer the ability to encrypt internal host names and IP addresses out of
the box, others require manual configuration, and yet others do not offer such a feature.
Obviously, using a product that does not encrypt poses the risk of an information leak,
but, perhaps more importantly, the fact that a product was designed with such an obvious
security flaw may be a harbinger of bigger problems; if a vendor did not consider even
basic security principles in designing a core component of its product, it is likely that
other, less visible areas of the product, were also implemented without proper security.

The following table summarizes an appropriate and recommended method for addressing the
various security concerns surrounding SSL VPN deployment:

Issue Solution
Server Side Security Issues
Open firewall ports Utilize Air Gap and do not open firewall ports
Application-level vulnerabilities Implement positive-logic application-level
filtering
SSL VPN Security Joseph Steinberg May 16, 2003

Page 8
Authentication Use strong two-factor authentication or one-
time passwords
Encryption Utilize 128-bit SSL
Browser Side Security Issues
Sensitive data may remain on insecure
access devices
Use a virtual shredder to wipe out any
temporary files, AutoComplete data, cookies,
history information, etc. that may have been
left at the browser
User credentials may be cached Replace HTTP Basic Authentication with a
secure, strong authentication scheme
Users may neglect to logout Use non-intrusive timeouts that are not
deceived by auto-refresh requests
Viruses and worms may tunnel into
the organization via the SSL VPN
Implement positive-logic application-level
filtering
Internal information may be leaked Encrypt all information related to internal
resources including host names and IP
addresses before transmitting to users


Caveat

One important caveat that is essential to understand when considering the deployment of an SSL
VPN is that an SSL VPN cannot totally replace the functionality of an IPSEC VPN. Although
SSL VPNs do offer greater convenience than IPSEC VPNs for the vast majority of users, most
organizations will likely find that a small set of technical users such as system administrators
and other MIS professionals do require the full network-level access afforded by IPSEC VPNs,
which SSL VPNs cannot provide (at least not in a secure fashion). As such, any Total Cost of
Ownership analysis performed on remote access technologies must account for the fact that even
when an SSL VPN is implemented, some smaller-scale IPSEC VPN architecture will likely
remain. Also, for site-to-site connectivity, IPSEC VPN clearly remains the technology of choice.

Conclusion

SSL VPNs, which offer great benefits over alternative remote access technologies, can be
deployed securely. The above information should provide a proper overview of the threats
inherent in SSL VPN implementations and of technologies to address them and help you plan
your deployment of this exciting new technology.
SSL VPN Security Joseph Steinberg May 16, 2003

Page 9

Joseph Steinberg is Director of Technical Services at Whale Communications
(www.whalecommunications.com), a leading provider of secure SSL VPN solutions. He can be
reached at joseph@whale-com.com.


Additional Sources

A Reverse Proxy Is A Proxy By Any Other Name
Art Stricek
SANS Reading Room
January 10, 2002
http://www.sans.org/rr/web/reverse_proxy.php

Application Level Content Scrubbers
Benjamin Sapiro
SANS Reading Room
August 22, 2001
http://www.sans.org/rr/firewall/scrubbers.php

Argus Events Infosecurity Europe Hacking Challenge 2001
http://www.argus-systems.com/events/infosec/

Disconnect from the Internet Whales e-Gap In-Depth
Kevin Gennuso
SANS Reading Room
September 13, 2001
http://www.sans.org/rr/firewall/egap.php

Introducing Air Gap Technology
Joseph Steinberg
PricewaterhouseCoopers Crytographic Centres of Excellence Journal
Issue #6 - March 2002
http://www.pwcglobal.com/extweb/pwcpublications.nsf/4bd5f76b48e282738525662b00739e22/
636e2aaf6ef835f685256b8f0044e2d0/$FILE/CCE%20Journal%20-%20Issue%206.pdf

Microsoft Security Bulletin (MS00-076) - Patch Available for 'Cached Web Credentials'
Vulnerability
October 12, 2000
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms00-
076.asp

Microsoft TechNet Article: Basic Authentication
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver
2003/proddocs/server/sec_auth_basicauth.asp

SSL VPN Security Joseph Steinberg May 16, 2003

Page 10
Neoteris Instant Virtual Extranet Cross Site Scripting Session Hijacking Vulnerability
May 7, 2003
http://www.securityfocus.com/bid/7510/discussion/

Network Air Gaps Drawbridge to the Backend Office
Michael Hurley
SANS Reading Room
April 4, 2001
http://www.sans.org/rr/firewall/gaps.php

Polish crackers beat hack challenge
April 23, 2001
http://www.vnunet.com/News/1120903

The e-Gap Remote Access Appliance Total Cost of Ownership Analysis: IPSEC Virtual
Private Network (VPN) vs. e-Gap Remote Access SSL VPN (with limited-scale IPSEC VPN
deployment)
March 2003
Whale Communications
http://www.whalecommunications.com/tco