SolutionBase: Security considerations for SSL VPN deployments

Security is always a major worry when you're dealing with mobile users. In this article, Tom Shinder discusses how to ensure that your SSL VPN connections are secure.

Remote access to information resources maintained on corporate networks is one of the most important business agility initiatives of our time. The ability to remotely access information located on the corporate network enables out of office workers to complete contracts, negotiate deals, and extend their work hours using information that would otherwise be inaccessible. Anytime, anywhere access to this information makes employees more productive and has significant potential to improve an organization's overall profitability.

However, there is a downside to the anywhere, anytime access story that can turn this story of increased productivity and profitability to one of business disaster. Enabling remote access to company hosted information resources not only exposes these resources to authorized employees, but also to unauthorized and possibly malicious outsiders. By properly implementing secure SSL VPNs, you can balance network security with network access for remote users.

What's wrong with traditional VPN Security?

Remote access virtual private networking has traditionally been used to enable secure remote access to corporate hosted information resources. While network level remote access VPNs succeeded in their goal in providing private connections between the remote access VPN client and corporate VPN server, they suffered from several limitations:

  • Remote access VPN connections provided a private connection, but did little to insure security on the link
  • Remote access VPNs usually treated the remote access VPN client as a virtual node on the corporate network and enabled unfettered access to any host using any protocol on the corporate network
  • Many organizations enabled split tunneling on VPN clients, which created the potential for the VPN client to act as a bridge between an untrusted network and the corpnet.
  • VPN client computers are often not corporate managed devices and do not conform to the software security requirements of managed computing devices
  • Many corporate firewalls either do not contain the protocol intelligence or are not configured to enable network level VPN connections to remote VPN servers
  • PPTP, L2TP/IPSec and IPSec tunnel mode remote access VPN clients and servers are typically difficult to setup and maintain. Many users, and even network administrators, have difficulty conceptualizing the notion of a remote host acting as a virtual node on the corporate network, leading to costly help desk calls

SSL VPNs as a solution

These and other cost intensive issues with network layer VPNs lead to the development and current growth of a collection of technologies known as "SSL VPNs". Unlike network level VPNs, where the only difference between the VPN types were the connection management and encryption protocols, so-called SSL VPNs are an extremely heterogeneous group of technologies.

Some examples of SSL VPN technologies include:

  • Client/server applications that are designed to support HTTP access to data contained within the server application. One of the best examples of this is Outlook Web Access (OWA). The OWA component is a integrated feature that enables access to Exchange hosted data via a Web connection and automatically formats the data so that it can be viewed through any Web browser
  • SSL VPN application gateways that enable HTTP access to server applications that do not have a native Web based interface. The SSL VPN gateways are able to receive responses from the non-Web enabled server application and reformat it so that the returned data can be presented in a Web browser
  • SSL VPN gateways that act as "de-tunneling" Web proxies. These SSL VPN gateways accept HTTP connections from a client application, removes the HTTP header from the native client/server protocol and forwards the native protocol to the server application. One of the best known examples of this type of SSL VPN is the Outlook 2003/Exchange Server 2003 RPC over HTTP protocol
  • True remote access VPN connections that use SSL as an application transport all network protocols. These types of SSL VPNs are relatively rare, but provide the same level of network access and protocol support seen with network level VPNs

Reasons for Deploying SSL VPN Remote Access Solutions

I encounter a lot of companies who tell me "I need an SSL VPN". The problem is that when I ask them why they think they need an SSL VPN, they're unable to come up with a cogent answer. SSL VPN technologies are designed to solve specific problems and without an understanding of the problems they can solve, the SSL VPN customer might end up wasting tens of thousands of dollars for SSL VPN technologies they don't even need.

Companies might need an SSL VPN to solve one or more of the following problems:

  • Remote users are unable to access server based data on the corporate network because they are behind firewalls that do not support network level VPN connections through the firewall (PPTP, L2TP/IPSec and IPSec tunnel mode)
  • Users do not understand how to use client applications when connected to the VPN or they forget to initiate the VPN link before using these applications. This generates Help Desk calls that costs the company money
  • Users do not understand how to provision their VPN clients or do not understand how to change VPN client software settings to meet networking requirements forced on them based on their current location. This generates expensive Help Desk calls
  • Installing, configuring and managing network level VPN clients and servers consumes an inordinate amount of IT department resources
  • Remote users require access to a narrow subset information resources on the corporate network and you want to insure that the remote access solution does not enable access to more than the required resources
  • The company does not proactively manage all remote access client machines and needs to prevent machines that might have been compromised by viruses, worms, trojans, and spyware from infecting and compromising the corporate network

A conventional remote access VPN server and gateway can accomplish some of these goals, but not all of them. For example, the ISA Server 2004 firewall's VPN server component allows you to configure granular per-user/per-group access control over what protocols and servers VPN users can use and access when connected to the corporate network. However, an advanced firewall/VPN server like ISA Server 2004 cannot provide the simple and clear user interface that presents users straightforward access to network resources that they have permission to use.

Securing the SSL VPN Solution

You might be thinking of rolling out an SSL VPN solution in your own environment. If so, then I recommend that you consider in advance steps you can take to secure your SSL VPN remote access solution. There are a number of methods and technologies available that can help secure your SSL VPN connections, but the specific security solutions are targeted at the type of SSL VPN you bring into production.

While it's impossible to provide a comprehensive guide to SSL VPN security because of the diversity of SSL VPN technologies currently in use, we can review some of the more common security methodologies you can bring into play to shore up potential security weaknesses in your SSL VPN solution.

Security options we'll discuss in this section include:

Application layer inspection of SSL tunnels before they reach the SSL VPN gateway Perimeter firewall protection in front of network services accessed through the SSL VPN gateway Strong user and computer authentication at or prior to connecting to the SSL VPN gateway SSL VPN client "hygiene" technologies Web proxy servers on the corporate network that protect against SSL VPN tunnels that violate network use policy

Application Layer Inspection of SSL Tunnels Before They Reach the SSL VPN Gateway

One of the security advantages that both network level VPN and SSL VPN solutions provide is an encrypted, private connection between the remote user and the VPN or SSL gateway. The connection is private because users between the client and gateway are unable to access the information contained in the encrypted tunnel

However, the encrypted nature of these communications is a double-edged sword. While intruders and other malicious individuals are unable to steal information contained in the encrypted SSL stream, neither is your network firewall. Conventional firewalls and reverse Web proxy servers only see an encrypted SSL connection and forward that connection to the destination SSL endpoint, which is the SSL VPN gateway in this case.

The firewall is unable to provide network perimeter protection when the SSL VPN tunnels are forwarded uninspected from the remote SSL VPN client to the SSL VPN gateway. This can allow hackers or malicious mobile code to traverse your perimeter firewalls and reach the SSL VPN gateway uninspected and unmitigated. The end result is that it's almost like not having a firewall at all.

You can solve this problem by using a firewall that performs SSL to SSL bridging (sometimes referred to as SSL termination and initiation). Firewalls that perform SSL to SSL bridging accept the incoming SSL session from the SSL VPN client, decrypt the contents of the communication, perform application layer inspection of the commands and data within the HTTP communication, then re-encrypts the communication and forwards the connection to the SSL VPN gateway. This enables the firewall to stop exploits that would otherwise be hidden in an encrypted tunnel.

SSL to SSL bridging firewalls are useful for all SSL VPN solutions because SSL encrypted HTTP is a common thread throughout the entire spectrum of SSL VPN technologies. They are most effective for SSL VPN access to Web services that do not tunnel other application protocols inside an HTTP header.

There are a handful of firewalls that can perform this stateful application layer inspection of SSL encrypted tunnels. Two or the more popular SSL to SSL bridging solutions is ISA Server 2004 and Cyberguard.

Perimeter Firewall Protection in Front of Network Services Accessed Through the SSL VPN Gateway

While SSL to SSL bridging solutions significantly enhance the level of security for your SSL VPN connections to native Web services, the situation becomes more complex when implementing SSL VPN solutions that tunnel other application layer protocols inside an SSL encrypted HTTP header.

For example, Outlook 2003 when used in conjunction with Exchange Server 2003 supports the RPC over HTTP protocol (RPC/HTTP). RPC/HTTP (which is actually RPC/SSL) enables the Outlook 2003 client to wrap its native RPC protocol that it uses to communicate with an Exchange Server in an HTTP header so that it can tunnel the native Exchange RPC protocol through firewalls that support or allow TCP 443 outbound but do not support the complex Exchange RPC protocol.

After wrapping the Exchange RPC protocol in an HTTP header, the Outlook client sends the connection to an RPC/HTTP proxy at the destination network. The RPC/HTTP proxy removes the HTTP header from the communications and forwards the native Exchange RPC communications to the Exchange Server. The Exchange Server sends its responses to the RPC/HTTP proxy, the proxy wraps the response in an HTTP header, and then the RPC/HTTP proxy returns the response to the Outlook 2003 client.

While the RPC/HTTP protocol is a great boon for users located behind firewalls and NAT devices that do not have the application layer intelligence to support secure Exchange RPC communications, it can be a potential problem for network security.

For example, suppose you have an advanced firewall that can perform SSL to SSL bridging (such as ISA Server 2004). The advanced firewall can perform application layer inspection on the HTTP communications inside the SSL tunnel because it can decrypt and re-encrypt the SSL communications. However, there is no firewall at this time that can perform SSL to SSL bridging and perform application layer inspection on the native Exchange RPC protocols with in the HTTP tunneled datastream.

After the RPC/HTTP connection reaches the RPC/HTTP proxy, the HTTP header is removed and the native Exchange RPC protocol is exposed and forwarded to the Exchange Server. If an attacker or worm (such as Blaster) develops an attack against Microsoft RPC services that tunnel inside an RPC/HTTP connection, then the exploit will be exposed after reaching the RPC/HTTP proxy and forwarded to the Exchange Server, which can lead to disastrous results.

The solution is to place another firewall at a network services segment perimeter where the Exchange organization lies. Even though the front-end firewall was able to perform stateful packet and application layer inspection for the HTTP application layer transport, it is not able to inspect the native Exchange RPC protocol. Therefore, you will need a firewall in front of the Exchange network services segment that understands the Exchange RPC protocol and subjects it to strong application layer inspection and protocol conformance testing.

At this time, only the ISA Server 2004 firewall and Checkpoint are able to perform this level of Exchange RPC protocol inspection. The ISA Server 2004 Exchange RPC application filter is a bit more stable and definitely easier to implement than the Checkpoint offering from my experience.

The same principles apply to any other application layer protocol that may be tunneled in an HTTP header and forwarded to an SSL VPN gateway. You need to place a perimeter firewall that understands the native protocols exposed in the unwrapped communications and protect the server that receives the native protocols from the SSL VPN gateway's de-tunneled protocols.

Strong User and Computer Authentication At or Prior to Connecting to the SSL VPN Gateway

The SSL VPN gateway will always require the user to authenticate before allowing access to any network resources. Most SSL VPN gateways present the user with a customized landing page that contains links to resources that the user is authorized to access.

Most of the SSL VPN gateways support standard Windows authentication protocols, including Windows integrated, basic and digest. While these protocols might be considered adequate in some circumstances, they may not be the best choice for user authentication in a comprehensive SSL VPN rollout.

The reason for this is that while the goal of SSL VPNs is to allow anytime, anywhere access to corporate hosted information resources, it's not always a good idea to extend this concept to all computers.

For example, users might be lulled into a false sense of security based on the significant costs inherent in an SSL VPN solution. They figure that if a technology solution cost significantly more than an opposing solution (such as the significantly higher cost of SSL VPN over traditional network level VPNs), then it must confer almost magical levels of security.

This underlying belief may lead users to use computers in highly risky environments, such as airport kiosks. This is a dangerous situation because even if the SSL VPN solutions incorporate some type of client "hygiene" mechanism, there is no protection from shoulder surfing, hardware dongles, or inline keyloggers connected between the keyboard and computer.

Strong authentication prevents this type of risky behavior. Because two-factor authentication is very difficult to carry out in kiosk and similar environments and can completely bypass username/password authentication, it's the best choice for user authentication for your SSL VPN solution. There are many options available:

  • User certificate authentication
  • RSA SecurID authentication
  • Biometric authentication
  • Smart Cards

In addition to protecting your network from users who use kiosks, two-factor authentication protects your SSL VPN and entire network from users who try to help each other by sharing passwords. Password sharing is a significant security risk and can lead to the quick proliferation of the shared password inside and outside the organization.

SSL VPN Client "Hygiene" Technologies

A common problem with all VPN technologies is VPN client hygiene. VPN client hygiene refers to the "health" of the software environment on the VPN client system. Many VPN clients are not members of the corporate domain and fall outside the category is managed computers. Managed computers tend to maintain a more orderly software environment which is more resistant to virus, worm and spyware attack.

However, even managed computers can present a significant risk to the corporate network when connecting from remote locations. Because these machines have left the highly managed corporate environment and entered network environments that are either unmanaged or poorly managed, the risk of virus, worm or spyware attack on those systems is significant. This leads to potential spread of any exploit that has successfully ensconced itself on the remote VPN client device.

When considering an SSL VPN alternative, it's critical that you plan for some type of client hygiene solution. There are several approaches you can take to solve this problem:

  • Use network management and software deployment tools to enforce anti-virus and anti-spyware software on each managed host that connects to the network through the SSL VPN gateway
  • Select an SSL VPN solution that can perform advanced application layer inspection at the SSL VPN gateway on either or both the HTTP application transport protocol and the native protocols that may be de-tunneled by the SSL VPN gateway
  • Select an SSL VPN solution that performs some type of client hygiene check. If you go for one of these SSL VPN solutions, pay close attention to what is checked on the SSL VPN client device. Not all client hygiene checks are created equal and vary from cursory registry and browser checks to full fledged checking for an array of potential client security issues.
  • Deploy a mobile anti-virus, anti-spyware and access control solution. These mobile solutions enable a company to control where users go on the Internet even when they are not on the corporate network. These advanced solutions require that the mobile host be in contact with the corporate access control, anti-virus and anti-spyware servers over the Internet so that corporate client hygiene policies are enforced even when the host is off network. Leading solutions in this space include SurfControl and Sunbelt Software's Counterspy Enterprise product.

Web Proxy Servers on the Corporate Network that Protect against SSL VPN Tunnels that Violate Network Use Policy

This last security consideration relates to potential security issue emanating from SSL VPN clients located on your corporate network. SSL VPN clients pose the same risk to your network integrity as traditional network level VPN clients. Because the connections from SSL VPN clients cannot be fully inspected by your perimeter firewalls, viruses, worms, spyware and other exploits can be passed through your firewall from the remote network into your corporate network through the SSL VPN tunnel.

While there is very little you can do about stateful application layer inspection for traditional network level VPN connections through your perimeter firewalls, the problem isn't so insoluble for SSL VPN connections. There are solutions available that mirror the security advantages of inbound SSL to SSL bridging by performing outbound SSL to SSL bridging.

Outbound SSL to SSL bridging works a bit differently than inbound SSL to SSL bridging. With inbound SSL to SSL bridging, the perimeter firewall is the first termination point for the SSL connection from the SSL VPN client. The advanced firewall actually impersonates the SSL VPN gateway by presenting a Web site certificate with the subject name matching the gateway. You have complete control over the naming conventions used in your organization and there aren't very many names that you need to support in your public DNS and certificate infrastructure to make this work.

The situation isn't so simple with outbound SSL to SSL bridging. Since you don't have the same level of control over what servers internal network clients will make SSL connections to, the outbound SSL to SSL bridging gateway needs to be able to dynamically impersonate the destination to which the HTTP CONNECT is being forwarded to. To accomplish this task, the outbound SSL to SSL bridging gateway generates Web site certificates on the fly that contain the name of the destination SSL server in their subject names.

If this sounds like a panacea for strong stateful packet and application layer inspection for outbound SSL connections from the corporate network, it is. At least it is from a technical point of view. However, there are significant concerns loudly professed from privacy advocates who claim that if the company can statefully inspect outbound SSL connections, the company could potentially harvest personal information from user data that is putatively moving through an end to end SSL tunnel.

It's unlikely that this debate will end soon. The bottom line is whether the user's right to violate network use policy is stronger than the company's right to financial survival. You'll have to check with your company's legal arm before implementing this level of security against potential exploits introduced into your network by SSL VPN clients who tunnel application protocols through your network firewalls that you have otherwise blocked.

SSL VPNs can provide a secure solution

SSL VPNs represent a collection of technologies that enable remote access connections to corporate hosted information through an encrypted SSL tunnel. SSL VPNs have several advantages over traditional network level VPNs and these advantages are driving the accelerated uptake of SSL VPN solutions we see today. In spite of these advantages, SSL VPNs can create significant security risks to both your corporate network and networks from which the SSL VPN clients connect. We discussed several security technologies and methodologies you can use to help mitigate some of the risks inherent across the entire line of SSL VPN approaches.