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