NIST SP 800-113 日本語訳

Special Publication 800-113

Sheila Frankel Paul Hoffman Angela Orebaugh Richard Park

Guide to SSL VPNs

NIST Special Publication 800-113

原本PDFの抜粋画像

Recommendations of the National Institute of Standards and Technology

Sheila Frankel Paul Hoffman Angela Orebaugh Richard Park

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

July 2008

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

National Institute of Standards and Technology

James M. Turner, Deputy Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-113 Natl. Inst. Stand. Technol. Spec. Publ. 800-113, 87 pages (July 2008)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

Acknowledgements

The authors, Sheila Frankel of the National Institute of Standards and Technology (NIST), Paul Hoffman of the Virtual Private Network Consortium (VPNC), and Angela Orebaugh and Richard Park of Booz Allen Hamilton, wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content, especially Elaine Barker, Jim St. Pierre and Tim Polk of NIST. The authors would like to acknowledge Tim Grance and Karen Scarfone of NIST for their keen and insightful assistance throughout the development of the document. The authors particularly want to thank Guy Snyder, Darren Hartman and Thang Phan of ICSA Labs for their careful review and valuable contributions to improving the quality of this publication. The authors would also like to express their thanks to Mike Hillhouse of Juniper Networks and Mahesh Jethanandani of Cisco for their worthwhile comments and suggestions.

Secure Sockets Layer (SSL) virtual private networks (VPN) provide secure remote access to an organization’s resources. A VPN is a virtual network, built on top of existing physical networks, that can provide a secure communications mechanism for data and other information transmitted between two endpoints. Because a VPN can be used over existing networks such as the Internet, it can facilitate the secure transfer of sensitive data across public networks. An SSL VPN consists of one or more VPN devices to which users connect using their Web browsers. The traffic between the Web browser and the SSL VPN device is encrypted with the SSL protocol or its successor, the Transport Layer Security (TLS) protocol. This type of VPN may be referred to as either an SSL VPN or a TLS VPN. This guide uses the term SSL VPN. SSL VPNs provide remote users with access to Web applications and client/server applications, and connectivity to internal networks. Despite the popularity of SSL VPNs, they are not intended to replace Internet Protocol Security (IPsec) VPNs.¹ The two VPN technologies are complementary and address separate network architectures and business needs. SSL VPNs offer versatility and ease of use because they use the SSL protocol, which is included with all standard Web browsers, so the client usually does not require configuration by the user. SSL VPNs offer granular control for a range of users on a variety of computers, accessing resources from many locations. There are two primary types of SSL VPNs:

This publication discusses the fundamental technologies and features of SSL VPNs. It describes SSL and how it fits within the context of layered network security. It presents a phased approach to SSL VPN planning and implementation that can help in achieving successful SSL VPN deployments. It also compares the SSL VPN technology with IPsec VPNs and other VPN solutions. This information is particularly valuable for helping organizations to determine how best to deploy SSL VPNs within their specific network environments.

Implementing the following recommendations should assist in facilitating more efficient and effective SSL VPN use for Federal departments and agencies.

Federal agencies deploying SSL VPNs must configure them to only allow FIPS-compliant cryptographic algorithms, cipher suites, and versions of SSL.

Some organizations, such as Federal agencies, have strict requirements for encryption and integrity protection. SSL VPNs should support the required algorithms for symmetric encryption, key exchange, and hash functions. For government agencies, traffic that requires protection must employ Federal

Information Processing Standard (FIPS)-compliant cryptographic algorithms and modules. Many of the cryptographic algorithms used in some SSL cipher suites are not FIPS-approved, and therefore are not allowed for use in SSL VPNs that are to be used in applications that must conform to FIPS 140-2. This means that to be run in FIPS-compliant mode, an SSL VPN gateway must only allow cipher suites that are allowed by FIPS 140-2.

Some of the cryptographic requirements, including allowable hash functions and certificate key lengths, will change at the end of 2010. Therefore, Federal agencies who want to provide SSL VPN services after 2010 must ensure that their systems are upgradeable to the new FIPS-compliant cipher suites and key lengths before the end of 2010, and that their SSL VPN vendors guarantee that such upgrades will be available early enough for testing and deployment in the field.

Organizations planning SSL VPN deployments should identify and define requirements, and evaluate several products to determine their fit into the organization.

SSL VPN products vary in functionality, including protocol and application support. They also vary in breadth, depth, and completeness of features and security services. Some recommendations and considerations include the following:

Organizations should use a phased approach to SSL VPN planning and implementation.

A successful SSL VPN deployment can be achieved by following a clear, step-by-step planning and implementation process. The use of a phased approach can minimize unforeseen issues and identify potential pitfalls early in the process. The five phases of the recommended approach are as follows:

Organizations should be familiar with the limitations of SSL VPN technology.

SSL VPNs, although a maturing technology, continue to face several challenges. These include limitations on their ability to support a large number of applications and clients, the methods of implementing network extension and endpoint security, the ability to provide clientless access, the use of the SSL VPN from public locations, and product and technology education.

Organizations should implement other measures that support and complement SSL VPN implementations.

These measures help to ensure that the SSL VPN solution is implemented in an environment with the technical, management, and operational controls necessary to provide sufficient security for the SSL VPN implementation. Examples of supporting measures include:

Although SSL VPNs are flexible enough to meet many needs, there are certain cases when other types of VPNs may provide a better solution. Network layer VPN protocols, primarily IPsec; data link layer VPN protocols, such as Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and Layer 2 Forwarding (L2F); and application layer security protocols, including OpenPGP and Secure Shell (SSH), are all effective alternatives to SSL VPNs for particular needs and environments.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

This publication seeks to assist organizations in understanding SSL VPN technologies and in designing, implementing, configuring, securing, monitoring, and maintaining SSL VPN solutions. This document provides a phased approach to SSL VPN planning and implementation that can help in achieving successful SSL VPN deployments. It also provides a comparison with other similar technologies such as IPsec VPNs and other VPN solutions.

The publication has been created for computer security staff and program managers; system, network, and application administrators; and others who are considering the deployment of SSL VPNs. It is also useful for organizations that already deploy IPsec VPNs and want to know how IPsec and SSL VPNs are complementary.

The remainder of this document is organized into the following six major sections:

The document also contains appendices with supporting material. Appendices A and B contain a glossary and an acronym list, respectively.

This section provides a general introduction to network and transport layer security. Network layer security protects network communications at the layer that is responsible for routing packets across networks. Transport layer security provides security at the layer responsible for end-to-end communications. This section first introduces the Transmission Control Protocol/Internet Protocol (TCP/IP) model and its layers and then discusses the need to use security controls at each layer to protect communications. It provides a brief introduction to Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), primarily focused on the types of protection that SSL can provide for communications. This section also provides a brief introduction to virtual private networking (VPN) services and explains what types of protection a VPN can provide. It introduces three VPN architecture models and discusses the features and common uses of each model. This document discusses only the most common VPN scenarios and uses of SSL.

TCP/IP is widely used throughout the world to provide network communications. TCP/IP communications are composed of four layers that work together. When a user wants to transfer data across networks, the data is passed from the highest layer through intermediate layers to the lowest layer, with each layer adding information. At each layer, the logical units are typically composed of a header and a payload. The payload consists of the information passed down from the previous layer, while the header contains layer-specific information such as addresses. At the application layer, the payload is the actual application data. The lowest layer sends the accumulated data through the physical network; the data is then passed up through the layers to its destination. Essentially, the data produced by a layer is encapsulated in a larger container by the layer below it. The four TCP/IP layers, from highest to lowest, are shown in Figure 2-1.

Figure 2-1. TCP/IP Layers

Security controls exist for network communications at each layer of the TCP/IP model. As previously explained, data is passed from the highest to the lowest layer, with each layer adding more information. Because of this, a security control at a higher layer cannot provide protection for lower layers, because the lower layers perform functions of which the higher layers are not aware. Security controls that are available at each layer include:

Because they can provide protection for many applications at once without modifying them, network layer security controls have been used frequently for securing communications, particularly over shared networks such as the Internet. Network layer security controls provide a single solution for protecting data from all applications, as well as protecting IP information. Nevertheless, in many cases, controls at another layer are better suited to providing protection than network layer controls. For example, if only one or two applications need protection, a network layer control may be excessive. Transport layer protocols such as SSL are most commonly used to provide security for communications with individual HTTP-based applications, although they are also used to provide protection for communication sessions of other types of applications such as SMTP, Point of Presence (POP), Internet Message Access Protocol (IMAP), and File Transfer Protocol (FTP). Because all major Web browsers include support for TLS, users who wish to use Web-based applications that are protected by TLS normally do not need to install any client software or reconfigure their systems. Newer applications of transport layer security protocols protect both HTTP and non-HTTP application communications, including client/server applications and other network traffic. Controls at each layer offer advantages and features that controls at other layers do not. Section 3 contains detailed information on transport layer security controls. Information on data link, network, and application layer alternatives to transport layer controls is provided in Section 6.

IPsec⁴ has emerged as the most commonly used network layer security control for protecting communications, while SSL is the most commonly used transport layer security control. Depending on how IPsec and SSL are implemented and configured, both can provide any combination of the following types of protection:

A VPN is a virtual network, built on top of existing physical networks, that can provide a secure communications mechanism for data and other information transmitted between networks. Because a VPN can be used over existing networks, such as the Internet, it can facilitate the secure transfer of sensitive data across public networks. This is often less expensive than alternatives such as dedicated private telecommunications lines between organizations or branch offices. VPNs can also provide flexible solutions, such as securing communications between remote telecommuters and the organization’s servers, regardless of where the telecommuters are located. A VPN can even be established within a single network to protect particularly sensitive communications from other parties on the same network.

It is important to understand that VPNs do not remove all risk from networking. While VPNs can greatly reduce risk, particularly for communications that occur over public networks, they cannot eliminate all risk for such communications. One potential problem is the strength of the implementation. For example, flaws in an encryption algorithm or the software implementing the algorithm could allow attackers to decrypt intercepted traffic; random number generators that do not produce sufficiently random values could provide additional attack possibilities. Another issue is encryption key disclosure; an attacker who discovers a key could not only decrypt traffic but potentially also pose as a legitimate user. Another area of risk involves availability. A common model for information assurance is based on the concepts of confidentiality, integrity, and availability. Although VPNs are designed to support confidentiality and integrity, they generally do not improve availability, the ability for authorized users to access systems as needed. In fact, many VPN implementations actually tend to decrease availability somewhat, because they add more components and services to the existing network infrastructure. This is highly dependent upon the chosen VPN architecture model and the details of the implementation.

The following sections describe the two primary types of SSL VPNs: SSL portal VPNs and SSL tunnel VPNs. (There is a third type, SSL gateway-to-gateway VPNs, that is available in some implementations. These are rarely used because they have very similar features to IPsec VPNs but less flexibility; they are therefore not discussed in this document.) Both types of SSL VPNs are typically used to provide remote users access to multiple services controlled and administered by the SSL VPN gateway.

SSL VPN gateways are sometimes single-purpose hardware systems that contain the software needed to perform the SSL VPN tasks. In other cases, firewall and router hardware systems contain SSL VPN capabilities and thus become SSL VPN gateways when those capabilities are turned on in the system’s administrative interface.

It should be noted that, although there are standards for the TLS protocol, there are currently no standards for any type of SSL VPN.⁵ For example, SSL VPN features such as access control and endpoint security have not been standardized. Thus, the descriptions here are based on common implementations of SSL VPNs at the time this document was being prepared.

An SSL portal VPN allows a user to use a single standard SSL connection to a Web site to securely access multiple network services. The site accessed is typically called a portal because it has a single page that leads to many other resources. SSL portal VPNs act as transport-layer VPNs that work over a single network port, namely the TCP port for SSL-protected HTTP (443).

The remote user accesses the SSL VPN gateway using any modern Web browser, identifies himself or herself to the gateway using an authentication method supported by the gateway, and then is presented with a Web page that acts as the portal to the other services. These other services might be links to other Web servers, shared file directories, Web-based email systems, applications that run on protected servers, and any other services that can be channeled through a Web page.

To the user, an SSL portal VPN is a Web site with more options of services available after the user has authenticated. To access an SSL portal VPN, the user enters the portal’s URL in a Web browser just as the user would enter the URL for any other Web page. These URLs typically use the https: scheme to start SSL immediately, but many SSL VPNs allow users to first enter an http: URL that then redirects to a secure SSL port.

SSL portal VPNs work with essentially any modern Web browser. Specifically, they work with browsers whether or not the browsers allow (or support) active content. Thus, SSL portal VPNs are accessible to more users than SSL tunnel VPNs.

An SSL tunnel VPN allows a user to use a typical Web browser to securely access multiple network services through a tunnel that is running under SSL. SSL tunnel VPNs require that the Web browser be able to handle specific types of active content (e.g., Java, JavaScript, Flash, or ActiveX) and that the user be able to run them. (Most browsers that handle such applications and plug-ins also allow the user or administrator to block them from being executed.)

The “tunnel” in an SSL tunnel VPN is both similar and quite different from the tunnels seen in typical IPsec VPNs. The two types of tunnels are similar in that almost all IP traffic is fully protected by the tunnel, giving the user full access to services on the network protected by the VPN gateway. The tunnels are quite different in that SSL/VPN tunnels are usually created in SSL using a non-standard tunneling method, while IPsec tunnels are created with methods described in the IPsec standard.

The tunneling in an SSL tunnel VPN allows a wide variety of protocols and applications to be run through it. For example, essentially any protocol that runs over TCP or UDP can be tunneled through such a gateway, making the remote user’s experience of the protected network very similar to being directly on the network. To the user, an SSL tunnel VPN may appear quite different from a typical Web site because the tunneling plug-in or application needs to be loaded into the user’s browser before the user can access the VPN. This might involve warning messages about the software being loaded, and it could also prevent users from entering the VPN if their Web browsers are instructed not to allow such programs to run. Because of the active content requirement, SSL tunnel VPNs may be accessible to fewer users than SSL portal VPNs.

The administration of both SSL portal VPNs and SSL tunnel VPNs is similar. The gateway administrator needs to specify local policy in at least two broad areas:

Different SSL VPNs have very different administrative interfaces and very different capabilities for allowing access and specifying allowed actions for users. For example, many but not all SSL VPNs allow validation of users through the Remote Authentication Dial-In User Server (RADIUS) protocol. As another example, some SSL VPNs allow the administrator to create groups of users who have the same access methods and capabilities; this makes adding new users to the system easier than gateways that require the administrator to specify both of these for each new user.

Section 2 describes the TCP/IP model and its layers—application, transport, network, and data link—and explained how security controls at each layer provide different types of protection for TCP/IP communications. SSL, a transport layer security control, can provide several types of protection for data, depending on its configuration. The section describes SSL VPNs and highlights the two primary SSL VPN architecture models (SSL portal VPNs and SSL tunnel VPNs). The following summarizes the key points from Section 2:

SSL VPNs provide secure remote access to an organization’s resources. An SSL VPN consists of one or more VPN devices that users connect to using their Web browsers. The traffic between the Web browser and SSL VPN device is encrypted with the SSL protocol. SSL VPNs provide remote users with access to Web applications and client/server applications, and with connectivity to internal networks. They offer versatility and ease of use because they use the SSL protocol that is included with all standard Web browsers, so the client usually does not require configuration by the user.

This section of the document discusses SSL VPNs and their services and features. Section 3.1 provides an overview of the high-level SSL VPN architecture. Section 3.2 highlights the major functions of an SSL VPN. Section 3.3 describes the various features and services provided by SSL VPNs and the security controls used to protect the confidentiality, integrity, and availability of data. Section 3.4 briefly covers the technical details of the SSL and TLS protocols. Section 3.5 addresses the challenges involved with SSL VPNs.

Figure 3-1 provides a high level view of a typical SSL VPN architecture. That architecture is the same for both SSL portal VPNs and SSL tunnel VPNs.

Typical SSL VPN users include people in remote offices, mobile users, business partners, and customers. Hardware clients include various types of devices, such as public kiosks, home personal computers (PC), PDAs, or smart phones, which may or may not be controlled or managed by the organization. The SSL VPN may also be accessed from any location including an airport, a coffee shop, or a hotel room, as long as the location has connectivity to the Internet and the user has a Web client that is capable of using the particular SSL VPN. All traffic is encrypted as it traverses public networks such as the Internet. The SSL VPN gateway is the endpoint for the secure connection and provides various services and features (most SSL VPN products are standalone hardware appliances, although there are some software-based solutions that are installed on user-supplied servers).

Figure 3-1. SSL VPN Architecture

Providing secure remote access to a wide variety of users and devices at many locations calls for a diverse set of SSL VPN services and features. Most SSL VPNs have one or more of the following three core functions:

• Application Translation. Application translation converts information from one protocol to another. It is often used to convert a legacy or proprietary protocol into a more widely used or standard protocol. It is also used to facilitate system integration and communication between applications and devices. Application translation uses proxying to interact with both sides of the connection with the appropriate protocol. SSL portal VPNs use application translation for applications that are not Web-enabled. This allows users to use a Web browser to access applications that do not have their own Web interfaces. For example, to provide file server access, an SSL portal VPN would communicate with a file server using the appropriate protocol, such as the Common Internet File System (CIFS) or the File Transfer Protocol (FTP), and translate the information into a Web-based format so that users can view the information with a Web browser. Application translation requires a translator engine for each protocol that is supported.

The three core functions allow SSL VPNs to provide secure remote access to a variety of applications. SSL VPN products vary in quality and effectiveness by the way they implement these three core functions. For example, SSL VPN products may offer support for different protocols via proxy and application translation; others might offer more or less control of the level of network access for network extensions. When evaluating SSL VPN products, it is important to have identified the remote access needs and applications served.

In addition to the three core functions, SSL VPNs include other features and security services. These elements often vary in breadth, depth, and completeness, so side-by-side comparisons of SSL VPN products often result in more differences than similarities. Therefore, it is important to identify and define requirements, and evaluate several products. Common SSL VPN features include the following:

Common SSL VPN security services include the following:

Sections 3.3.1 through 3.3.8 provide details and examples of the various SSL VPN features and security services.

SSL VPNs offer a variety of manageability features such as status reporting, logging, and auditing. Status reporting includes identifying connected users and reporting usage data in a graphical format. Logging includes the ability to export logs, debug logging, and automate log rollover. Auditing includes auditing application access, RADIUS-based accounting, and persistent storage of auditing information. Another manageability feature is the ability to terminate sessions as needed.

A manageability feature that is often overlooked is documentation. It is beneficial to have documentation for SSL VPN usage, configuration, and troubleshooting. Documentation may also include context-sensitive help within the management interface.

Another manageability feature that is beneficial for SSL VPNs is partitioned or delegated management. This allows different aspects of the SSL VPN device to be managed by different groups or individuals. This feature can be beneficial for service providers, collocation facilities, and organizations with different groups sharing the SSL VPN device. It is also quite useful for an SSL VPN to be able to be managed remotely, such as by a system administrator who is not on-site. Remote management requires greater security to prevent attackers from watching and possibly altering the management sessions; in SSL VPNs, this security is normally provided by running all remote management sessions under SSL.

Two other important features for SSL VPNs are high availability and scalability. High availability solutions use two or more SSL VPN devices configured in either active/passive or active/active mode. In an active/passive solution, one device actively services connections, while the other device is waiting in standby mode. The two devices continuously exchange “heartbeat” messages to communicate their status with one another. If the standby device does not receive a heartbeat message from the active device for a preconfigured time period, it will assume that the active device is no longer operating and take over servicing connections. In an active/active solution, both devices are actively servicing connections at the same time. If one device fails, the other device will service all connections if it has been properly sized to do so. High availability allows the SSL VPN to survive the loss of a device or device component.

In either active/passive or active/active mode, one of the challenges of high availability is properly propagating and sharing information between the devices. Another challenge is maintaining state information about existing connections in the event of a failure. SSL VPN proxying and network extension functionality each handle state information differently. Another consideration is transparency of failover to the users. Depending on how state information is shared, the user may or may not need to re-authenticate after a failure.

SSL VPNs support scalability with load-balancing features. Both high availability and load balancing often use a virtual IP address that is shared across multiple SSL VPN devices. In an active/passive architecture, the passive device has the ability to take over the virtual IP address and associated traffic if the active device fails. In an active/active architecture, both devices service the virtual IP address. SSL VPN devices configured as active/passive typically are not providing any scalability features, whereas active/active configurations use either an integrated load balancer or an external load balancer to distribute connections across multiple VPN devices. However, for the VPN to maintain functionality when one of the devices fails, it is essential to ensure that the VPN traffic load does not exceed the throughput capability of a single device.

Portal customization is a feature that allows an administrator to control the appearance of the SSL VPN Web interface that the end users see and with which they interact. Note that both SSL portal VPNs and SSL tunnel VPNs usually have portal pages: SSL tunnel VPNs often have portal pages for users to change their settings, request help from a system administrator, and so on.

Some products lack portal customization features; nevertheless, finding the right files on the SSL VPN device and editing them may allow customization of the look and feel of the portal. Other products have built-in configuration settings to control the colors, icons, and layout of the portal. Some products only provide system-wide customization, while others allow portal customization on a per-group basis. Besides layout and color preferences, customized portals are often necessary to support PDAs and smart phones over SSL VPNs. Some products allow portal customization per system type to accommodate the limited functionality of PDAs and smart phones. Portal customization sometimes integrates with the endpoint security controls and access control. If an end system does not pass all of the endpoint security checks and access is restricted, the user may be presented with a limited portal.

Some advanced products also have the capability to allow users to control the layout and customization of their own portals. This includes creating bookmarks, adding icons, and saving passwords.

SSL VPNs support the authentication security service either directly through an integrated authentication method, or indirectly via an external authentication server, or both. Traditional SSL Web page authentication relies on server-side authentication, so that users trust the server with which they are communicating. SSL VPN authentication takes this a step further by requiring both server-side and client-side authentication. SSL VPNs support flexible client authentication methods, such as username and password, smart cards, two-factor authentication, and X.509 digital certificates. For the use of methods involving tokens, the SSL VPN must be able to handle the various messages, such as PIN change requests, that are involved in token solutions.

When digital certificates are used for client authentication, each endpoint has its own digital certificate that contains a public key. An endpoint uses the corresponding private key to digitally sign data before sending it to the other endpoint, which verifies the signature using the peer’s public key. The digital signature algorithm choices are RSA and the Digital Signature Standard (DSS). In addition to authentication with certificates, the SSL VPN should also support certificate revocation list (CRL) checking. The SSL VPN should be able to generate certificate-signing requests for its own digital certificates. Note that most SSL VPNs that allow digital certificates for client authentication do so using proprietary mechanisms; this is because client digital certificate authentication often does not work well in typical Web browsers, which provide a difficult user interface for users who have many client certificates issued for different purposes.

In addition to the authentication methods already mentioned, SSL VPNs also support integration with external authentication servers such as RADIUS, Active Directory, and Lightweight Directory Access Protocol (LDAP), allowing the VPNs to leverage existing authentication databases. SSL VPNs need access to group information on the authentication servers since security and access control are often expressed in terms of groups. Some SSL VPN products also use the information contained in authentication servers to make additional access control decisions, such as restricting the number of bad password attempts. Windows Active Directory (AD) is a common type of authentication server that can be accessed directly or by using LDAP. Some SSL VPN products do not support direct AD authentication. To access AD via LDAP, the administrator must have strong knowledge of the underlying structure of the directory. In this case, it is easier and less time consuming to use an SSL VPN with the capability to communicate directly with AD.

SSL VPN authentication methods may be applied on an individual or group basis. One class of users may use a specific form of authentication and another class may use a different form of authentication. For example, employees may authenticate via username and password, and business partners may authenticate via digital certificates. Some SSL VPN products have the capability to combine various forms of authentication methods, such as using a digital certificate in addition to a username and password. Because integration with authentication servers is an area where SSL VPN products vary greatly, potential products should be evaluated with an organization’s authentication servers to verify interoperability.

SSL VPNs use the underlying SSL protocol to protect the confidentiality of data using encryption and to provide data integrity (ensuring that the data has not been modified). SSL VPN’s encryption and data integrity come from SSL itself, not from any feature added by the SSL VPN product. SSL ensures the encryption and data integrity between the user’s computer and the VPN gateway. Many SSL VPNs also support using SSL between the gateway and Web hosts on the protected network for applications that require encryption and integrity protection even within the protected network.

SSL VPN products vary greatly in their access control features. Some products have an allow policy for the entire system by default, which allows authenticated users complete unrestricted access to the protected network. This may be adequate for a wide open network, but in most SSL VPN implementations, the organization will be providing different services to different types of users and will want controlled access. Granular access control supports one of the fundamental goals of SSL VPNs: to provide access to a variety of groups and users such as mobile employees, branch offices, business partners, and customers. Some SSL VPN products allow highly granular access control, which can include the particular application or file being accessed, day and time, type of browser, authentication method used, computer type and location, user identification, and other characteristics. The SSL VPN uses an access control policy to provide different services based on these characteristics.

Table 3-1 provides examples of typical access control policies. Access privileges may be granted to individuals, groups, or resources. For ease of configuration, access control is typically configured based on groups. Each user is assigned to one or more groups, each group having certain security parameters. Group information may be accessed from the authentication database, such as the LDAP directory. Access control may also be defined for a set of resources instead of an individual resource. This makes adding and removing resources to and from a group transparent to the users and reduces policy complexity. In some specific instances, user-level parameters are also set.

Table 3-1. Access Control Examples

Access control can also be integrated with endpoint security controls. SSL VPNs can use host integrity checking to check the status of the SSL VPN client before access is granted. Some SSL VPNs have the capability to perform this checking either before or after authentication to determine the appropriate access controls. Access control in this sense may be as simple as allowing or denying access completely, or more elaborate such as providing restricted access to selected information based on host integrity checks. Access controls may also be configured per-user, per-group, and per-resource in terms of host integrity checking. It is beneficial to have the ability to bypass the endpoint security restrictions for certain circumstances such as disaster response. Bypassing endpoint security for special circumstances may be accomplished through a special access control policy setting or whitelist.

Table 3-2 shows some examples of access control policies in conjunction with endpoint security controls. These examples are an extension of the examples in Table 3-1. The first user is the CEO, who is accessing the SSL VPN from home via an organization-issued laptop. The firewall and antivirus software pass the security checks since they are enabled and up-to-date. Based on user and group access policies, and the passing of the endpoint security checks, the CEO may access the intranet servers, email, the executive folder of the administrative server, and the Community Relations server. The next user is John Smith, who is a traveling member of the sales team. He is attempting to access the SSL VPN from a public computer in an Internet café. The firewall passes the security checks, but the antivirus software is not up-to-date on its signatures. Based on user and group access policies and the fact that only some of the security checks passed, John is granted access to email and the ability to download (but not upload) files from the sales server (he would have been given more privileges if he had passed all the security checks). He may also access the Community Relations server. The last user is Sally Jones, who is an employee at a business partner, XYZ Corp. She is attempting to access the SSL VPN from a trusted partner network. Based on user and group access policies, and the passing of the endpoint security checks, Sally is granted access to the extranet partner server and the Community Relations server.

Table 3-2. Access Control Examples with Endpoint Security Controls

Knowing the needs and requirements for the SSL VPN solution, such as the types of users and the reasons they will use the SSL VPN, will help organizations choose a product with the appropriate level of access control capability. These needs and requirements will also help organizations determine the level of granularity needed for access controls.

Some SSL VPNs provide endpoint security controls that include host integrity checking and security protection mechanisms. Host integrity checks help ensure that the client system is in compliance with an organization’s security policy. These checks are performed before a session is begun and may be periodically rechecked during the session.

Endpoint security controls are sometimes tightly integrated with access control to analyze the client system and apply access controls based on the results. For example, an up-to-date company-issued laptop that is connecting from a remote site might be allowed full access. Another example is a personal laptop that complies with the standard firewall and antivirus checks but is attempting access from an untrusted wireless hotspot, and thus is granted only limited access. Endpoint security controls also include security protection mechanisms, such as Web browser cache cleaners that remove temporary files, cookies, and other session information from the Web browser used for SSL VPN access. This supports the use of the SSL VPN from public locations.

Endpoint security controls can be implemented in a variety of ways, and this often differentiates products. Endpoint security starts with a policy definition. The policy definition includes what the host integrity checker should look for and the actions to take depending on what it finds. If host integrity checkers are used, they should be configured to execute before the logon process to look for malware such as keystroke loggers. Typical host integrity checks may look for operating system type and version, antivirus and personal firewall status and configurations, or a specific file, registry key, or running process. Depending on the product, checking for running processes may be as simple as looking for the process name or as elaborate as verifying the actual validity of the process.

Some SSL VPN products include their own integrated endpoint security software. This software may be part of the SSL VPN product or an add-on for an additional cost. Other SSL VPN products rely on third-party software for endpoint security. This allows organizations to leverage their existing products, such as cache cleaning tools, malware scanners, and compliance checking software, with their SSL VPNs. Some of these SSL VPNs can only integrate with a single specific third-party product, while others can integrate with a variety of third-party products.

Some SSL VPN products provide endpoint security controls for systems that are connecting into the network via the network extension function. Such systems are generally of higher concern than those that are just accessing Web sites, since these systems are usually granted much broader access to resources.

Endpoint security controls should be used with care. Due to the nature of remote access, the client systems are more likely to be originating from uncontrolled environments. It is imperative that remote systems are evaluated before allowing access to internal resources and cleaned after access is granted. There is no industry-wide standard for endpoint security controls; many leading network and security companies are working to create vendor-driven standards.

Some SSL VPN products provide an integrated intrusion prevention security service. They inspect the contents of the data after it has been decrypted by the SSL VPN for potential attacks and various forms of malware, including viruses and worms. The SSL VPN may include its own anti-malware and intrusion detection software, or it may integrate with third-party software. Performing content inspection adds processing time and latency to the throughput of packets. For high-volume networks, this latency in addition to the latency of the encryption and decryption process may exceed tolerable limits. In those cases, it is best to offload the intrusion prevention capabilities to a specialized intrusion prevention system (IPS) device on the inside of the trusted network (that is, after the SSL VPN has decrypted the data).

The security of the data sent over an SSL VPN relies on the security of the SSL protocol. The SSL protocol allows a client (such as a Web browser) and a server (such as an SSL VPN) to negotiate the type of security to be used during an SSL session. Thus, it is critical to make sure that the security agreed to by the remote user and the SSL gateway meets the security requirements of the organization using the SSL VPN.

There are three types of security that the client and server can negotiate: the version of SSL, the type of cryptography, and the authentication method. All three are important to the security of the communications channel that is established and are thus important to SSL VPN systems. These are discussed in more detail in Sections 3.4.1 through 3.4.3.

NIST Special Publication (SP) 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations⁶, describes the technology used in SSL and TLS in detail. Readers of this document who want to know more about these technologies are encouraged to read that publication.

In this document, the terms SSL and TLS are often used together to describe the same protocol. In fact, SSL refers to all versions of the SSL protocol as defined by the IETF, while TLS refers only to versions 3.1 and later of the SSL protocol. Two versions of TLS have been standardized: TLS 1.0 and TLS 1.1. TLS 1.0 is the same as SSL 3.1; there are no versions of SSL after 3.1. As of the writing of this guide, work is being done on TLS version 1.2. TLS is approved for use in the protection of Federal information; SSL versions other than 3.1 are not.

Different SSL VPNs and different Web browsers use different versions of the SSL and TLS protocols. For example, some browsers support SSL 3.0 but not TLS 1.0 or 1.1; other browsers support TLS 1.0 but not SSL 3.0. Because each version of SSL or TLS is incompatible with other versions, both the browser and the SSL VPN have to have at least one version of SSL in common. Further, they both have to have a version in common that meets the security policy of the organization running the SSL VPN; otherwise, the browser and the SSL VPN gateway will not be able to communicate.

There are many types of cryptographic functions that are used in security protocols. The most widely known cryptographic features are confidentiality (secrecy of data), integrity (the ability to detect even minute changes in the data), and signature (the ability to trace the origin of the data). The combination of these features is an important aspect of the overall security of a communications stream. SSL uses four significant types of features: confidentiality, integrity, signature, and key establishment (the way that a key is agreed to by the two parties).

SSL uses cipher suites to define the set of cryptographic functions that a client and server use when communicating. This is unlike protocols such as IPsec and S/MIME where the two parties agree to individual cryptographic functions. That is, SSL exchanges say in effect, “Here is a set of functions to be used together, and here is another set I am willing to use.” IPsec and S/MIME (and many other protocols) instead say, “Here are the confidentiality functions I am willing to use, here are the integrity functions I am willing to use, and here are the signature algorithms I am willing to use”, and the other side creates a set from those choices.

Just as the SSL client and server need to be able to use the same version of SSL, they also need to be able to use the same cipher suite; otherwise, the two sides cannot communicate. The organization running the SSL VPN chooses which cipher suites meet its security goals and configures the SSL VPN gateway to use only those cipher suites.

When a Web browser connects to an SSL server such as an SSL VPN gateway, the browser user needs some way to know that the browser is talking to a server the user trusts. SSL uses certificates that are signed by trusted entities to authenticate the server to the Web user. (SSL can also use certificates to authenticate users to servers, but this is rarely done.)

The server authentication occurs very early in the SSL process, immediately after the user sends its first message to the SSL server. In that first message, the Web browser specifies which type of certificate algorithms it can handle; the two common choices are RSA and DSS. In the second message, the SSL server responds with a certificate of one of the types that the browser said it understands. After receiving the certificate, the Web browser verifies that the identity in the certificate (that is, the domain name listed in the certificate) matches the domain name to which the Web browser attempted to connect.

Some SSL VPNs use certificates issued by the vendor of the SSL VPN, and those certificates do not link through a chain of trust to a root certificate that is normally trusted by most users. If that is the case, the user should add the SSL VPN's own certificate to the user's list of directly-trusted certificates. It is important to note that users should not add the root certificate of the SSL VPN's manufacturer to the list of certification authorities that the user trusts, since the manufacturer’s security policies and controls may differ from those of the organization. Other SSL VPNs produce self-signed certificates that do not chain to any trusted root certificate; as before, the user should add the SSL VPN's own certificate to the user's list of directly-trusted certificates.

Certificates are signed with keys of a specified length. The security of the authentication is linked to the length of the key that is protecting the identity in the certificate. If an SSL server uses a key of insufficient length to protect its identity, the Web client might not want to trust the identity at all. In most Web browsers, there are mechanisms to check the length of the key that was used by the SSL server after the browser has successfully made an SSL connection.

SSL VPNs are rapidly maturing technologies. Nevertheless, they still face several challenges:

SSL VPNs can support a range of users, on a variety of computers, accessing resources from many locations. They can provide secure remote access to internal services such as email, file servers, and other applications in a Web-based format. SSL VPNs use the SSL protocol, which is included in all standard Web browsers, to secure the transmission of data between the user and the organization as it traverses public networks.

SSL VPNs consist of three core functions to enable secure access to internal resources. These functions—proxying, application translation, and network extension—provide multiple methods to enable remote access to a variety of applications. This allows SSL VPNs to support Web-based, client/server, and legacy applications. Proxying provides the simplest form of an SSL VPN by enabling encryption and authentication for internal Web sites. Application translation is often used to access non-Web-enabled applications by converting a legacy or proprietary protocol into a more widely used or standard protocol. Network extension provides complete network access to remote users as if they were physically located on the internal local area network. Users with network extension can access all network resources, not just Web servers; this is particularly useful in organizations with custom applications that cannot be translated to the Web easily.

SSL VPNs vary in breadth, depth, and completeness of features and security services. This makes it important to identify and define requirements, and evaluate several products to determine their fit into the organization. Recommendations and considerations include the following:

Several of the security services provided by SSL VPNs rely on the underlying SSL protocol. SSL VPNs may use versions of either SSL or TLS protocols. The choice of which protocol to implement depends on the data being secured. For example, TLS is approved for use in the protection of Federal information; SSL versions other than 3.1 are not. The SSL VPN must be configured to ensure that the appropriate protocol is used. This also applies to the security mechanisms that SSL and TLS use to secure communications.

Not all SSL VPN products include all of these services, and there are differences in the level of sophistication of the services that are supported. The main differentiators for SSL VPN products are how they implement security policies and handle remote clients, and how transparent their usage is to the end user. The strengths of an SSL VPN include support for a variety of systems and locations, granular access control, Web browser client access, and ease of use.

SSL VPNs, although a maturing technology, continue to face several challenges. These include limitations on their ability to support a large number of applications and clients, the methods of implementing network extension and endpoint security, the ability to provide clientless access, the use of the SSL VPN from public locations, and product and technology education.

This section focuses on the planning and implementation of SSL VPNs in the enterprise. As with any new technology deployment, SSL VPN planning and implementation should be addressed in a phased approach. A successful SSL VPN deployment can be achieved by following a clear, step-by-step planning and implementation process. The use of a phased approach can minimize unforeseen issues and identify potential pitfalls early in the process. This section explores in depth each of the recommended SSL VPN planning and implementation phases, as follows:

Organizations should also put into place other measures that support and complement SSL VPN implementations. These measures help to ensure that the SSL VPN solution is implemented in an environment with the technical, management, and operational controls necessary to provide sufficient security for the SSL VPN. Examples of supporting measures include:

The purpose of this phase is to identify which resources or services need to be available for remote access and who should be able to access them through the SSL VPN. It is also important to identify other general and application-specific requirements, such as performance, and to think about future requirements. For example, if it is likely that other resources will need to be accessible by remote users in a year, then those needs should also be considered.

One of the primary strengths of an SSL VPN architecture is its granularity of access control. An organization should leverage this feature by being specific in its identification of resources, the users who can access them, and other security requirements. It is helpful to begin this process by articulating a set of organizational requirements for remote access. These requirements are not strictly technical but are dictated by the needs of the organization. Here are a few examples of organizational requirements:

The next step is to determine other requirements such as anticipated performance requirements (normal and peak loads), service level agreement (SLA) guarantees, and the use of multiple languages.

The organization should consider the best possible technical solution once its requirements are identified. It is possible that other protocols such as SSH or IPsec provide a better technical solution than SSL. This is especially pertinent if a VPN solution already exists, because it could potentially be leveraged to meet the identified requirements. See Section 6 for descriptions of such protocols and guidance on when a particular protocol may be a viable alternative to SSL. SSL may be the only option in some cases, such as when granularity on a per-application basis is required for remote access or if the VPN needs to be available to remote users without any software or hardware installation.

Federal agencies are required to use cryptographic algorithms that are NIST-approved and contained in FIPS-validated modules. The FIPS 140-27 specification defines how cryptographic modules will be validated. One requirement of FIPS 140 is that the module be capable of operating in a mode where all algorithms are NIST-approved. NIST-approved algorithms are specified in a FIPS (e.g., FIPS 180, Secure Hash Standard⁸) or in a NIST Recommendation (e.g., SP 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography⁹). Where there are no NIST-approved algorithms in a specific class, such as key transport, the Cryptographic Module Validation Program (CMVP) Implementation Guidance may specify additional constraints. Because SSL VPN technology employs a number of cryptographic algorithms, Federal agencies must be aware of whether their chosen SSL VPN technology is FIPS-compliant now and whether it is expected to be FIPS-compliant during the entire expected lifetime of the system.

Many of the cryptographic algorithms used in some SSL cipher suites are not FIPS-approved, and therefore are not allowed for use in SSL VPNs that are to be used in applications that must conform to

FIPS 140-2. This means that to be run in FIPS-compliant mode, an SSL VPN gateway must only allow cipher suites that are allowed by FIPS 140-2.

NIST SP 800-5210 lists the TLS cipher suites that satisfied FIPS requirements as of its publication date (June 2005); additional cipher suites meeting FIPS requirements may become available in the future. All of the cipher suites listed in SP 800-52 will become disallowed after the end of 2010. Therefore, Federal agencies who want to provide SSL VPN services after 2010 must ensure that their systems are upgradeable to the new FIPS-compliant cipher suites before the end of 2010, and that their SSL VPN vendors guarantee that such upgrades will be available early enough for testing and deployment in the field. Further, those systems must be able to be configured to only use cipher suites with FIPS-compliant hash functions. Otherwise, a client that is offering a cipher suite with non-compliant cryptographic functions might negotiate an SSL session that does not rely on FIPS-compliant technologies.

Because of the way that SSL was designed, SSL versions 3.0 and earlier do not conform to the requirements of FIPS 140-2. Therefore, SSL VPNs that are to be used in applications that must be FIPS-compliant must use TLS 1.0 (SSL 3.1) or later for their SSL VPN systems. Further, those systems must be able to be configured to only use TLS 1.0 or later; otherwise, a client that is using SSL 3.0 or earlier might use the SSL negotiation to cause the SSL VPN gateway to create an SSL session that is inappropriate for the security level of the organization. A client that only uses SSL 3.0 or earlier should not be permitted to establish an SSL VPN connection; nevertheless, few SSL VPNs have the capability to enforce this restriction.

NIST SP 800-56A¹¹, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, defines the types of key establishment algorithms that can be used in FIPS-compliant systems that use cryptography such as Diffie-Hellman key exchange. As described in NIST SP 800-52, the method for key establishment in SSL version 3.1 and later that is preferred by NIST is ephemeral Diffie-Hellman.

The ephemeral Diffie-Hellman key establishment used by TLS version 1.0 and later does not meet the requirements of NIST SP 800-56A. NIST has granted a special exception from this requirement for systems using SSL until the end of 2010; see Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program¹². Subject to the results of further analysis, the date may be extended. SSL’s RSA key establishment method, which is not covered by the restrictions in NIST SP 800-56A, is acceptable now and beyond 2010.

Therefore, purchasers of SSL VPNs who need to be FIPS-compliant after the end of 2010 must ensure that their SSL VPN systems can be configured to require RSA key establishment at that time. Until that time, SSL VPN systems can also use the NIST-preferred method of ephemeral Diffie-Hellman.

SSL VPN devices that are to be used in FIPS-compliant applications must also use FIPS-compliant hash functions. Plain SHA-1 can only be used until the end of 2010 in FIPS-compliant systems¹³. The keyed-hash message authentication code (HMAC) form of SHA-1 is still considered secure, and can be used after 2010. Since SSL VPN devices use HMAC-SHA-1, those suites that employ this hash function will remain acceptable beyond 2010.

SSL VPN devices that are to be used in FIPS-compliant applications must use FIPS-compliant encryption. Fortunately, virtually all SSL VPN devices can do this. Further, those systems must be able to be configured to only use cipher suites with FIPS-compliant encryption; otherwise, a client that is offering a cipher suite with non-compliant encryption might use the SSL negotiation to cause the SSL VPN gateway to create an SSL session that is inappropriate for the security level of the organization.

Some SSL VPN devices can be configured to only allow certain cipher suites, or at least to only allow cipher suites with certain types of encryption. Other SSL VPN devices do not allow such configuration. NIST SP 800-52 lists the types of encryption that satisfied FIPS requirements when it was published (June 2005); additional encryption algorithms meeting FIPS requirements may become available in the future.

Finally, FIPS compliance for SSL VPNs requires the use of FIPS-compliant key sizes and hash functions for signatures in the certificates used for authentication. Fortunately, virtually all SSL VPN devices are able to do this today. Further, those systems must be able to be configured to only use FIPS-compliant key sizes and hash functions in these certificates; otherwise, a client or server whose certificate uses a non-compliant key size or hash function might use the SSL negotiation to cause the SSL VPN gateway to create an SSL session that is inappropriate for the security level of the organization.

Note that the list of allowed hash functions will change at the end of 2010. After that time, server certificates that use the SHA-1 hash function will no longer be allowed, and all FIPS-compliant SSL VPN devices will need to use certificates that use the SHA-256 hash function. Some SSL VPN devices today cannot use such certificates as the server authenticating certificate. Further, not all Web browsers today support certificates that use the SHA-256 hash function for authentication.

SSL server authentication certificates can use either the RSA or DSS signature schemes, although many SSL VPN systems and most Web browsers only support RSA. Note that if a server authenticates itself with a Digital Signature Algorithm (DSA) certificate, the key negotiation must use the ephemeral Diffie-Hellman method. That method is not allowed to be used after the end of 2010, and therefore SSL VPN systems that use DSA certificates cannot be used after the end of 2010 unless the special exception allowing the use of ephemeral Diffie-Hellman for SSL key establishment is extended. For DSA, a FIPS 186-314 compliant digital signature is required for the larger key sizes.

At the current time, few (if any) SSL VPN gateways can be configured to reject certificates based on the size of the key used and therefore most can be used in FIPS-noncompliant modes without any way to prevent such use. Worse, few (if any) SSL VPN gateways even log the size of the key used in certificate authentication, so it is not possible to audit which sessions are FIPS-compliant. Worse yet, few (if any) SSL VPN browsers can be configured to reject server certificates based on the size of the key used and therefore most can be used in FIPS-noncompliant modes without any way to prevent such use.

To guarantee FIPS compliance, SSL VPNs that cannot enforce requiring particular key sizes need to be configured with both of the following settings:

It is important to note that the minimum FIPS-compliant key length for DSA and RSA certificates will change at the end of 2010 from 1024 bits to 2048 bits; see Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program for more information.

Once the requirements have been identified, and it has been determined that an SSL VPN is the best solution, the next phase is to design a solution that meets the specified requirements. This phase is broken into five major components that are described in more detail in the following subsections.

After the organization determines what resources will be accessible and by whom, the next step is to design the access control policy. The organization should base this policy on the organizational requirements that were identified in the Identify Requirements phase. These requirements stipulate which resources should be accessed by which groups or individuals. The access control policy could provide additional requirements and make access to resources dependent on other characteristics such as the authentication method used, computer type and location, and user identification.

The four major steps in designing an access control policy are as follows:

Conditions are based on the ability of endpoint security controls to perform host integrity checking on the client hosts. Host integrity checking, which is discussed in more detail in Section 4.3.2, involves performing checks on conditions, including the type of operating system on the client machine, the presence of a firewall or antivirus scanner, registry settings, authentication method used, and time of day. These conditions will help determine what resources are accessible by the user. For example, users logging in from an organization-managed host would have access to more resources than if they were to log in from a public system at an Internet café.

A limited type of network extension, port forwarding, is sometimes used instead of full network extension. Port forwarding only creates tunnels for certain TCP or UDP ports instead of for all ports at one time. For example, a port forwarding system might tunnel HTTP traffic but not DNS traffic, leaving the DNS traffic outside of the VPN. Because port forwarding technology is a subset of network extension, this document discusses only network extension.

Most SSL VPN devices offer packet filtering for users that access resources via network extension. Because network extension provides broad access to users, the most effective way to protect certain subnets may be to configure packet filters that prevent access to them. SSL VPN devices may also support multiple routing tables for users. One routing table can be used to provide access to all internal subnets, while another routing table enables connectivity to subnets that only specific groups should access.

The following is an example of an organization’s access control requirements. The organizational requirements listed in the Identify Requirements phase are repeated here as a reminder:

The resources that should be made accessible by the SSL VPN are then specified:

The groups that should be able to access resources are as follows:

These are the conditions by which resources can be accessed by groups:

Note that these conditions are not mutually exclusive and can be fulfilled simultaneously. So a user who logs in from an organization-managed host also satisfies the any host condition.

The organization has decided to use the following access types for the various resources:

Table 4-1 shows the resources and groups listed with conditions for access.

Table 4-1. Sample Access Control Policy

Users are added to the various groups to grant them access to resources via the SSL VPN. For example, regular employees are added to the Employees group, while executives are added to both the Executives and Employees groups. A user in the Employees group who logs in from an organization-managed host is granted access to both the corporate applications and Web applications resources. This same user is restricted to only Web applications if the host cannot be verified as organization-managed.

Note that the access policy is configured to restrict access to the executive file share only to users who belong to the Executives group and are logging in from an organization-managed host. An executive is only given the access privileges of a regular employee if he or she logs in from any other host. If desired, users could also use a different authentication method to receive access to the executive file share.

This access control policy assumes that a user can satisfy multiple conditions simultaneously. For example, a user who logs in from an organization-managed host also satisfies the any host condition and is granted access to the corresponding resources. If the SSL VPN device cannot support this flexibility, then the organization would have to specify the resources for each condition.

Once the organization designs its access control policy, it should consider constructing a policy to enforce endpoint security. Such a policy could initially verify that a client host complies with an organization’s security policy by requiring host integrity checks to be performed on the client host. It is recommended to run the checks before the login process to look for malware such as keystroke loggers or viruses.

The checks can prohibit login altogether if the client host does not comply with the organization’s minimum security policy. For example, the organization’s endpoint security policy may specify that desktop search tools that index the contents of a user’s hard drive are prohibited during an SSL VPN session because these tools can cache data from the session. If this is the case, then the host integrity checking process may either turn off the search tools directly or prevent login until the tools are explicitly turned off by the user.

Some SSL VPN vendors perform the host integrity checks by having the client host dynamically download active content from the SSL VPN device and then execute the active content. In this case, the client operating system and browser need to be configured to permit these agents to be downloaded and executed; otherwise, the client could perceive the agents as malware and block them, preventing the SSL VPN from performing the host integrity checks. This shows a basic conundrum of using this type of integrity check: some organizations prohibit such active content to be run in browsers because it is difficult to distinguish it from malware.

An endpoint security policy should also specify how to enforce endpoint security on a client system after the user has logged out. Security protection mechanisms such as a cache cleaner can be activated during the logout process to remove data that was cached or saved during the SSL VPN session. For even higher security, some SSL VPN vendors offer the capability of putting the session into a virtual storage space. The SSL VPN device allocates temporary memory and hard drive space for it. On a Windows machine, the virtual storage space may consist of temporary My Documents and Desktop directories. The user is not able to save anything to a directory outside of the virtual storage space. After the user logs out, the entire virtual storage space and all data downloaded during the session is erased. This virtual space may also be encrypted for greater security. Not all applications may be compatible with the virtual storage space because some of the user’s directories are temporarily replaced, and interoperability problems could result. Also, the organization will have to make a policy decision about when to put users into the virtual storage space. For example, it may make sense to allow users to access their entire hard drive and keep downloaded files or email attachments if they are logging into the SSL VPN from their own organization-managed hosts.

If a user forgets to log out, the SSL VPN device should be able to perform an automatic logout after a specific period of inactivity. Ideally the device could detect and ignore activity that is automatic, such as an email client that periodically connects to the mail server or automatic refresh requests by a Web browser. The device may also have a separate timeout threshold to require re-authentication regardless of inactivity. This timeout limits the damage that is done if a malicious user somehow gets control of the VPN session. Some SSL VPN devices may have different timeout thresholds for different types of users. For example, users who are put into a virtual storage space might have much shorter timeout thresholds than users who log in from an organization-managed machine.

The following is an example of an endpoint security policy that is based on the access control policy described in the previous section. The access control policy is based on a user’s host meeting one of three conditions: organization-managed host, any host, or correct IP address and time:

The endpoint security policy is based on the access control policy and elaborates on host integrity checking and the post-login process:

If an organization has an endpoint security policy, it should deploy SSL VPN devices that can support those policies. This is especially important because endpoint security controls vary widely by device and vendor. As with authentication, each organization should conduct testing during its evaluation process to determine the endpoint security capabilities of each device being considered.

After the organization determines how resources are to be accessed and how access control and endpoint security are to be enforced, the next step is to decide on an authentication scheme for clients. The organization should choose a scheme consistent with its security policy. For example, if two-factor authentication is already required in the enterprise, then it should also be used for SSL VPN client authentication¹⁵. The flexible nature of SSL VPNs, however, may require further elaboration in policy. Authentication based on digital certificates requires each host to have a certificate installed, so the organization will have to decide what type of access to permit from hosts that do not have certificates, such as hosts owned by employees or public computers. An organization might not want to allow its certificates to be installed or used on hosts that are not managed by the organization. In the case of public computers, even certificates that are stored on an external device may not work, since many public computers have their USB ports blocked to prevent the unauthorized installation of malware.

Existing external authentication infrastructures should also be leveraged if feasible. Many SSL VPN products support LDAP, RADIUS, and Active Directory, so they can be configured to access authentication servers using any of these options. The authentication server can provide group information for authenticated users, such as whether a user belongs to the Sales or Executives group, so the SSL VPN device can enforce the organization’s access control policy.

SSL VPN authentication methods may be applied on an individual or group basis. This feature enables an organization to choose one form of authentication for one group, such as the Employees group, and another form of authentication for another group, such as the Executives group. The organization may also choose to base the authentication method on the specific resources, with some resources requiring stronger authentication than others.

Table 4-2 illustrates sample authentication methods for the resources defined in the previous example. Because access to the executive file share, sales database, and network infrastructure is considered to be especially sensitive, it requires two-factor authentication where the user must also use a physical token to be authenticated to the resource.

Table 4-2. Sample Authentication Methods Table

Various SSL VPN products can use internal databases, combine external authentication servers with an internal database stored on the SSL VPN device itself, or just use external authentication. Either the SSL VPN database or the authentication server database can contain user-specific information, such as preferences for portal settings and bookmarks for Web sites. For ease of management, user information should be stored on the external authentication server whenever possible to reduce the amount of duplicated information, which can get out of sync.

In addition to user authentication, the organization should also evaluate different server authentication options. The SSL VPN device requires an SSL server certificate so it can authenticate itself to clients. The organization can purchase a server certificate signed by a trusted certificate authority (CA), have the server certificate signed by its own CA if it already has a public key infrastructure (PKI) in place, or give the server a self-signed certificate. A user then validates the credentials of the SSL VPN device by decrypting the certificate with the issuer’s public key and possibly chaining to a trust anchor such as the trusted CA. The type and issuer of the server certificate may determine whether users from other organizations can access the VPN.¹⁶

Because integration with authentication servers is an area where SSL VPN products vary greatly, an organization should ensure that whatever product it chooses is able to support its authentication requirements. Any potential products should also be tested with the existing authentication servers to verify interoperability.

The architecture of the SSL VPN implementation refers to the selection of devices and software to provide SSL VPN services and the placement of SSL VPN devices within the existing network infrastructure. This section focuses on specific recommendations such as selection of hardware configuration, device placement and firewall configuration, routing policy and other network considerations, high availability or load balancing support, device management, client software selection, and portal design.

A key decision to be made for the SSL VPN implementation is the type of hardware configuration to use for the SSL VPN device. There are three main types of hardware configuration: a hardware appliance, an upgrade to an existing security product, and a software solution.

Device placement of the SSL VPN hardware is often a challenging task because the placement has security, functionality, and performance implications. It may also have an effect on other network devices such as firewalls, routers, and switches. Incorporating an SSL VPN device into a network architecture requires strong overall knowledge of network and security policy.

It is important to understand that the cryptographic protection of the SSL VPN only extends from client machines to the SSL VPN device. After the device receives the traffic from users, it is decrypted and forwarded in its original form to the destination. So if client traffic is originally sent in plaintext before it is encrypted with SSL, it is sent in plaintext from the VPN device to its destination. The SSL VPN device preserves most of the fields in the packet headers, with the exception of the source IP address and source TCP or UDP port.

There are three main options for SSL VPN device placement: as part of the organization’s firewall, within the internal network, or within a demilitarized zone (DMZ). Placing the SSL VPN device outside the organization’s firewalls is not recommended because the device itself receives no protection from the firewall.

Enabling VPN functionality on the firewall. This design integrates the firewall and SSL VPN device. The most common scenario is for an existing firewall product to be upgraded so it supports SSL VPNs. This option is made available by the vendor as either a software upgrade or hardware add-on. TCP port 443 for the firewall’s external address must be opened on the firewall to permit users to initiate SSL VPN connections. The firewall/SSL VPN device then communicates directly with internal hosts. Figure 4-1 illustrates this design.

Figure 4-1. Firewall with SSL VPN Functionality

This approach has some advantages and disadvantages when compared to the other options:

Advantages:

Disadvantages:

Placing the VPN device in the internal network. This option places the VPN device entirely within the internal network behind the firewall. TCP port 443 for the address of the SSL VPN must be opened in the firewall to access the device. Figure 4-2 illustrates this design. Although it is not shown in the diagram, placement of an additional firewall between the SSL VPN device and the rest of the internal network is highly recommended. That ensures both front-end and back-end protection for the SSL VPN device.

Figure 4-2. SSL VPN Device in Internal Network

Here are the advantages and disadvantages as compared with the other options:

Advantages:

Disadvantages:

Placing the VPN device within the DMZ. This design protects traffic between the device and internal hosts as well as the device itself from external attacks. The only port that must be opened in the firewall to access the device is TCP port 443 (https). Figure 4-3 illustrates an example of a network design where the VPN device is placed in the DMZ. The DMZ is a network segment attached to a firewall interface. Although it is not shown in the diagram, placement of an additional firewall between the SSL VPN device and the internal network is highly recommended. That ensures both front-end and back-end protection for the SSL VPN device. An alternate approach is a two-DMZ architecture, placing the SSL VPN device, front- and back-ended by a firewall, on a separate DMZ segment.

Figure 4-3. SSL VPN Device in DMZ Network

This approach has some advantages and disadvantages when compared to the other options:

Advantages:

Disadvantages:

It is recommended that if the VPN device is placed in the DMZ then it should be configured with two interfaces. Remote users use the external interface to connect to the device, while traffic destined for the internal network traverses the internal interface. This internal interface is connected to either another firewall or another interface on the same firewall. Figure 4-4 illustrates this design.

Figure 4-4. SSL VPN Device with Two Interfaces

This approach has the following advantages and disadvantages compared to the other options:

Advantages:

Disadvantages:

If the organization decides to place the VPN device within the DMZ, it must decide how many holes to open in its firewall between the device and the internal network. If the organization must support many services through the SSL VPN then it may decide to completely open up all connectivity between the VPN device and the internal network. This enables VPN users to access any machine and port internally. The benefits of such an approach will have to be weighed against the costs of potential security issues.

Routing policy is as important as firewall configuration. Packets must be routed correctly within the internal network for the VPN to function properly. When the VPN components of proxying and application translation are used, routing is fairly straightforward. Packets from the VPN device that are destined for the internal network have the source address of the VPN device itself. As long as the VPN device’s source address is routable in the internal network, packets will be correctly routed from internal hosts back to the VPN device.

If network extension is used, routing becomes more complicated. Network extension creates a point-to-point tunnel interface between the client machine and the VPN device. Each end of the tunnel is assigned a virtual IP address. The client’s virtual IP address is used as the source address of VPN packets from the client machine. Even after traffic from the client machine reaches the VPN device and is taken out of the SSL tunnel, the source address remains the same. This means that internal hosts must know how to route the client’s virtual IP address back to the VPN device, or routing will not work correctly.

For example, a client establishes a VPN connection using network extension. It receives the address of 192.168.1.200. The VPN device receives 192.168.1.1 for its virtual tunnel interface. When the VPN device forwards packets from the client to internal hosts, these internal hosts will receive packets with a source address of 192.168.1.200. If the internal routers cannot route these packets back to the VPN device, then the client will not be able to communicate with any internal hosts.

Another option is to use Network Address Translation (NAT) for clients using network extension. If NAT is used, then all packets forwarded from the VPN device to the internal network are given the source address of the VPN device. The routing configuration can therefore remain unchanged because it is assumed that internal hosts can already route traffic to the VPN device. This approach has its own disadvantages. The biggest one is that it is no longer possible to track the network activity of VPN clients by IP address because all of them share a single address. For this reason it is recommended that NAT not be used for clients using network extension.

One more issue with network extension that must be addressed is split tunneling. Split tunneling is defined as the process of allowing a remote VPN user to access a public network, most commonly the Internet, at the same time that the user is allowed to access resources on the VPN. A client machine that establishes a split tunnel connection with the VPN device does not send all of its network traffic through the VPN tunnel. It sends all traffic not destined for the internal (protected) network through its standard network connection and only sends traffic destined for the internal network through the VPN tunnel. Split tunneling offers the advantages of efficiency and bandwidth conservation, as traffic destined for the Internet does not have to be sent first to the VPN device. On the other hand, split tunneling also creates a potential security vulnerability. If an attacker from the Internet compromises the client machine, then this attacker can use the split tunnel to also access the organization’s internal network. The organization must weigh the advantages and disadvantages of split tunneling before deciding to implement it.

If split tunneling is implemented, then the organization must decide which IP addresses will be routed through the split tunnel. If all of an organization’s IP addresses are assigned to internal hosts, then the routing is straightforward, but some hosts may be in the DMZ and therefore publicly accessible. Traffic destined for these DMZ hosts will bypass the firewall if split tunneling is not used. It may therefore be more secure and efficient for the client to reach hosts located in the DMZ via the Internet rather than to use the split tunnel. If this is the case, then the organization must take care to configure the split tunnel with internal subnets only.

Section 4.3.4.2 recommends that a VPN device placed into the DMZ be configured with at least two interfaces: one for external traffic and one for internal traffic. However, using two interfaces introduces more routing complexity. The device needs to be configured with static routes that correctly point toward internal hosts or hosts in the DMZ. The routing tables for routers within the DMZ must also be configured to route all traffic destined for both interfaces on the device toward the device’s external interface. If any traffic is routed toward the device’s internal interface, this traffic may get dropped because it must traverse a firewall to reach the internal interface. This firewall will have no knowledge of the traffic because the original traffic from the VPN device to the DMZ hosts traversed the device’s external interface and therefore did not go through the firewall. Figure 4-5 illustrates a scenario where traffic will get dropped if the packets are not correctly routed to the right interface.

Figure 4-5. Routing Problem with SSL VPN Traffic

One final consideration for overall network policy is the issue of multiple sites. If the organization wants multiple sites to support SSL VPN services, then it must decide how to configure authentication and routing. There are several possibilities:

Note that the routing issues mentioned earlier in this section are also relevant for an architecture with multiple sites. Each site must be sure to correctly route and to not block VPN packets with addresses assigned at other sites. If the VPN devices have multiple interfaces, the packets destined for the external interface may have to be routed differently from packets destined for the internal interface. This depends on how the internal connectivity between sites is configured.

An organization may decide to implement high availability or load balancing. High availability may be required so the organization can meet service level agreements (SLA) for guaranteed uptime, or load balancing may be required to support a large number of users. SSL VPN products vary widely in how they support high availability and load balancing. For this reason, an organization with a need for high availability or load balancing should answer at least these questions about each device under evaluation, with testing possibly being required to receive detailed answers.

Configuration and upgrading pose additional issues. Some devices mirror configuration settings across devices, so only the active devices should be configured. Any altered settings on the passive devices will quickly be overwritten by the active device’s settings. If configuration settings are not mirrored, all devices should be configured with identical settings at the same time.

For upgrades, the vendor’s instructions for upgrading should be followed. Some vendors require the passive device in an active/passive mode architecture to be upgraded first. After this upgrade is complete, the newly upgraded device becomes active and the newly passive device can then be upgraded. Other vendors require the active device to be upgraded first. The active device is still handling VPN traffic while it is being upgraded and only fails over to the passive device when it is ready to reboot with the new upgrade in place. Upgrading the active device first avoids a scenario where the passive device is being upgraded and receives mirrored configuration changes from the active device in the middle of the upgrade process.

The organization should design a management policy to determine who will manage the SSL VPN device and by what means. Some devices offer a partitioned or delegated management feature that allows different aspects of the device to be managed by different groups or individuals. For example, a group that manages IT for the sales department can control access control and endpoint security policies for sales resources only. System administrators can manage endpoint security regarding the type and number of patches that each client machine must have installed.

If multiple interfaces on the SSL VPN device are used, the management policy should also specify which interface permits administrative access. Some devices provide flexibility in selectively enabling administrative access on each interface, as well as permitting this access only from specific IP addresses. Various forms of authentication for administrative access may also be supported, such as smart cards and two-factor authentication. If the organization is using multiple interfaces, administrative access is commonly only configured on the interface connected to the internal network for security reasons (although allowing management from the external interface over an SSL-protected tunnel is also considered secure). If administrative access is permitted on the external interface, a stronger form of authentication than username and password should be used.

The management policy should also discuss the means of backing up and restoring the device configuration. The specific procedures will vary by device but will include a means of transferring the configuration to another computer for archiving, and of retrieving this configuration. Some devices also support the ability to create a complete image of the operating system and configuration. This feature is useful for restoring every aspect of the device’s functionality at a specific point in time.

Although SSL VPNs are described as clientless, some forms of SSL VPN access such as network extension require dynamically downloaded agents to be run on the host. Even before login, the client machine may have to execute a dynamically downloaded agent that performs host integrity checks. The organization will have to ensure that these agents can run on client machines if the agents are required by access control and endpoint security policies. Once logged in, users can use common Web browsers to use the SSL VPN via proxy, but network extension requires particular browsers or versions of those browsers because they require other downloadable agents that establish the virtual network connection. If some systems such as public kiosks cannot download and execute these dynamically downloadable agents, then the organization will have to make a decision about the level of access to offer to these machines. Many SSL portal VPNs will work from all common Web browsers, but many SSL tunnel VPNs require particular browsers, and particular versions of those browsers.

The organization should provide a portal for users so they can login to the SSL VPN and gain access to internal resources. The portal can either be supplied by the SSL VPN device vendor or developed by the organization itself. If the organization chooses to use the portal supplied by the SSL VPN device vendor, it can customize it to match the appearance of the organization’s intranet.

Portal customization features vary widely by device, but the organization should be able to alter graphics, colors, and possibly icons and the layout of the portal. The functionality of the portal will depend on the type of access to the SSL VPN. For example, resources that rely on proxying and application translation will require some sort of icon or hyperlink in the portal so users can access them. Access via network extension also requires a hyperlink or icon on the portal to initiate the network extension process. Once this takes place, however, the portal is not required to access resources because the client machine has direct access to these resources via the network extension. An organization’s access control policy could determine the hyperlinks or icons that are displayed in the portal. For example, if the access control policy prohibits a user from using network extension, then the hyperlink or icon enabling network extension should not be displayed. Figure 4-6 depicts an example of a generic SSL VPN portal interface.

Figure 4-6. Example Portal Interface

The organization should choose a cryptography policy that fits its needs and is compliant with its requirements. In addition, Federal agencies must use only cryptographic modules whose algorithms and methods are compliant with the FIPS 140-2 specification. This topic is discussed in detail in Section 4.2.

In addition to what has already been discussed in this section, there are other possible design considerations. The following items describe issues not addressed earlier:

Table 4-3 provides a checklist that summarizes the major design decisions made during the first two phases of the SSL VPN planning and implementation process.

Table 4-3. Design Decisions Checklist

After the SSL VPN solution has been designed, the next step is to implement and test a prototype of the design. This could be done in one or more environments, including a laboratory network, a test network, and a production network. Ideally, implementation and testing should first be performed with a laboratory network, then a test network. Only implementations in final testing should be placed onto a production network. Aspects of the solution to evaluate include the following:

Application and client interoperability is a key requirement for a successful SSL VPN implementation. This is especially important because of the diversity of both the accessible applications and the potential user client environments. It is difficult to predict how a specific client will interoperate with a specific application through the SSL VPN.

Some examples of potential interoperability issues are as follows:

The best way to determine if there are interoperability issues is to test as many configurations as possible in a lab or test environment. The most popular configurations of all target operating system platforms (e.g., Windows, Mac OS X, Linux) should be tested with the most popular Web browsers (e.g., Internet Explorer, Firefox, Opera, Safari). The testing process should also attempt to verify that the organization’s applications are accessible in each commonly used browser and operating system. It is impossible to test every single permutation of client environment because of the wide variety of possible configuration settings on each machine, but at least a default configuration of each commonly used operating system and browser should be tested.

Disk imaging technologies could be helpful in the interoperability testing process. Baseline images of each operating system could be created and then restored to the baseline after each iteration of testing. This practice helps to ensure consistency during the testing process and may help to identify specific configurations that result in interoperability problems. Virtual machine technology could also be helpful in a similar way, where a “snapshot” of the baseline operating system running in a virtual machine is created and then restored after each testing iteration. Virtual machine technology streamlines the interoperability testing process by vastly reducing the time to restore a machine to its initial baseline condition.

If interoperability problems are discovered, the organization should work with the SSL VPN device vendor to troubleshoot them. Helping the vendor to replicate these problems is essential for this process. The problems may be solved by configuration changes, patches provided by the vendor, or modifications to the application or operating system that is causing the problem. If an interoperability problem with an application cannot be solved, the organization may have to reconsider whether it will be possible to enable remote access for the application.

Once testing is complete and any issues have been resolved, the next phase of the SSL VPN planning and implementation model involves deploying the solution. It is important to launch a pilot program before enterprise-wide deployment. A pilot program should consist of users who will be helpful for testing the SSL VPN solution for interoperability, functionality, and usability. Pilot users should fall in a broad range of technical knowledge levels to evaluate the organization’s ability to answer a wide variety of technical questions regarding the SSL VPN solution. At the same time, the limited nature of a pilot program helps to identify a set of problems that could potentially affect a greater audience, while offering the opportunity to fix these problems before the SSL VPN is used by the entire enterprise.

Part of the pilot program includes end user training and help desk support to assist users in understanding and using the SSL VPN’s features. End users can either be trained in hands-on sessions or larger lectures. Users also require documentation that serves as a reference in supplementing the training. Help desk personnel should receive more detailed technical training so they can help users to troubleshoot problems and walk them through the process of establishing VPN connectivity. If the pilot program is small enough, the group deploying the SSL VPN solution may provide technical support to pilot users, with training for help desk personnel occurring later.

After the pilot program has been launched, it is recommended that the organization gradually migrate existing network infrastructure, applications, and users to the new SSL VPN solution. This phased deployment provides administrators an opportunity to evaluate the impact of the SSL VPN solution and resolve issues before enterprise-wide deployment. Most of the issues that can occur during SSL VPN deployment are the same type of issues that occur during any large IT deployment.

The organization should also produce technical documentation somewhere in the deployment phase. The documentation should include the following:

Typical issues that could arise at various stages of the deployment process are as follows:

The last phase of the SSL VPN planning and implementation model lasts the longest. Managing the solution involves maintaining the SSL VPN architecture, policies, software, and other components of the deployed solution. Examples of typical maintenance actions are testing and applying patches or software updates to the SSL VPN devices, deploying SSL VPN connectivity to additional remote sites, renewing SSL server certificates that are going to expire, and adapting the policies as requirements change. It is also important to monitor the performance of SSL VPN components so that potential resource issues can be identified and addressed before performance becomes seriously degraded. Another important task is to perform testing periodically to verify that the access controls are functioning as expected. Any new hardware, software, or significant configuration changes start the process again at the Identify Requirements phase. This ensures that the SSL VPN solution lifecycle operates effectively and efficiently.

Another aspect of managing the SSL VPN solution is handling operational issues. For example, poor performance may be caused by connection problems such as fragmentation. Fragmentation occurs when network packets are broken down into smaller fragments, which then need to be reassembled at the receiving host. A network sniffer such as tcpdump or Wireshark is typically very helpful in troubleshooting SSL VPN connections. A sniffer allows the administrator to analyze the communications as they take place and correct problems. Because SSL traffic is encrypted and may not be decipherable from a standard packet capture, some SSL VPN devices provide decrypted network sniffing capability so that connectivity from one of the VPN endpoints may be analyzed. SSL VPN device logs and client logs may also be valuable resources during troubleshooting. Additionally, firewall and router logs may validate whether the SSL VPN traffic is reaching them, passing through them, or being blocked.

This section describes a phased approach to SSL VPN planning and implementation and highlights various issues that may be of significance to implementers. The following summarizes the key points from the section:

This section summarizes the information presented in the previous sections as a manageable and actionable set of recommendations that organizations can implement to provide reasonable assurance that their SSL VPN solutions are providing adequate security and are themselves secured properly. To be effective, an SSL VPN should have its security considerations incorporated throughout the entire IT life cycle, involving everything from policy to operations. This section references a five-phase life cycle model to help organizations determine at what point in their SSL VPN deployments a recommended practice might be relevant. The model is based on one introduced in NIST SP 800-64, Security Considerations in the Information System Development Life Cycle²⁰. Organizations may follow a project management methodology or life cycle model that does not directly map to the phases in the model that is presented in this section, but the types of tasks in the methodology and their sequencing are probably similar.

Table 5-1 presents the recommended practices corresponding to the life cycle phases. Each recommendation is accompanied by a brief explanation of the rationale for its inclusion and section reference for more information, and is rated as recommended practice or should consider. Organizations are strongly encouraged to adopt the recommended practices. Failure to implement them significantly increases the risk of an SSL VPN security failure or makes it more difficult to assess the overall security of the SSL VPN system. Organizations should also examine each of the should consider recommendations to determine their applicability to the target environment. In general, should consider measures enhance security beyond what can be achieved through the recommended practices. A should consider should be rejected only if it is infeasible or if the reduction in risk from its implementation does not justify its cost.

Table 5-1. SSL VPN Life Cycle Phase Recommendations

Although SSL VPNs are flexible enough to meet many needs, there are certain cases when other types of VPNs may provide a better solution. This section lists several VPN protocols that are used as alternatives to SSL VPNs in different scenarios. This section groups the types of VPN by the approximate layer of the TCP/IP model at which they function, because many of the protocols’ characteristics are based on the layer they use. SSL is the prevalent transport layer VPN protocol; this section discusses several data link layer, network layer, and application layer VPN protocols. For each protocol, a brief description is provided, along with a description of the circumstances under which it may be more advantageous than an SSL VPN.

Data link layer VPN protocols function below the network layer in the TCP/IP model. This means that various network protocols, such as IP, Internetwork Packet Exchange (IPX), and Network Basic Input/Output System (NetBIOS) Extended User Interface (NetBEUI), can usually be used with a data link layer VPN. Most VPN protocols, such as IPsec, only support IP, so data link layer VPN protocols may provide a viable option for protecting networks running non-IP protocols and for networks running more than one network protocol (such as IP and IPX at the same time).

The most commonly implemented data link layer VPN protocols are typically used on top of the Point-to-Point Protocol (PPP) and are most often used to secure modem-based connections. PPP, not the VPN protocol itself, typically provides encryption and authentication services for the traffic. The standards for PPP only reference supporting Data Encryption Standard (DES) for encryption and Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) for authentication. Because there are known weaknesses in these algorithms, data link layer VPN protocols often make use of additional protocols and services to provide stronger encryption and authentication for VPN connections. The most commonly used data link layer VPN protocols are as follows:

L2TP was intended to replace PPTP and L2F. When configured properly, L2TP combined with IPsec can provide strong encryption and authentication. PPTP should not be used to protect communications because of its known weaknesses. Because L2F can provide only limited protection for portions of communications that involve a participating ISP, L2TP should be used instead of L2F when the link from the remote user to the ISP needs to be protected (which is normally the case). L2TP with IPsec is a viable option for providing confidentiality and integrity for dial-up communications, particularly for organizations that contract VPN services to an ISP.

Network layer VPN protocols apply to all applications and are not application-specific. This allows some or all network communications between two hosts or networks to be protected without modifying any applications. IPsec is the most common network layer security control used to create VPNs. It is a framework of open standards for ensuring private communications over public networks. IPsec protocols work together in various combinations to provide protection for communications. The primary components of IPsec include the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange (IKE), and IP Payload Compression Protocol (IPComp).²²

In many environments, network layer controls such as IPsec provide a much better solution than transport or application layer controls because of the difficulties in adding controls to individual applications. Another advantage of network layer controls is that since IP information (e.g., IP addresses) is added at this layer, the controls can protect both the data within the packets and the IP information for each packet. Nevertheless, network layer controls provide less control and flexibility for protecting specific applications than transport and application layer controls.

As discussed in Section 2.1, each application layer protocol provides protection for only a single application. In many cases, the protocol protects only a portion of the application data. For example, the S/MIME and OpenPGP application protocols can be used in conjunction with email servers to encrypt the body of an email, but not the email headers (which include addressing information). Doing the encrypting at the mail server creates a secure path between the mail servers, but only for the data covered by the cryptographic changes.

It is difficult to call such encryption a VPN. It is not a network: it is a set of paths. Even if the entire message is encrypted, such as with Voice over IP (VoIP) that is using encryption, it is by no means a network: it is just a collection of encrypted data. Thus, it is incorrect to call anything above the network layer a “VPN”, although many companies market their application-layer encryption products as such.

A commonly used application layer protocol suite is Secure Shell (SSH), which contains secure replacements for several unencrypted application protocols, including telnet, Remote Copy Protocol (RCP), and FTP. The SSH client program itself provides protection for remote logins to another system. Some organizations extend the use of the SSH application by establishing SSH tunnels between hosts, and then passing other communications through the tunnels. This allows many applications to be protected at one time through a single tunnel. Generally, the tunnel is constructed between a remote user’s system and a server within the organization that the user can log into. Because a single SSH tunnel can provide protection for one or more applications at the same time, it is technically a transport layer VPN protocol, not application layer.

SSH tunnel-based VPNs are resource-intensive to set up. They require the installation and configuration of SSH client software on each user’s machine, as well as the reconfiguration of client applications to use the tunnel. Each user must also have login privileges on a server within the organization. Generally, users need to have solid technical skills so that they can configure systems and applications themselves, as well as troubleshoot problems that occur. Because of this, using SSH tunnels as a VPN is uncommon, particularly when compared to SSL VPN deployment.

Section 6 describes the main alternatives to SSL VPNs. Data link layer VPN protocols, such as PPTP, L2TP, and L2F; network layer VPN protocols, primarily IPsec; and application layer “VPN” protocols, including OpenPGP and SSH, are all effective alternatives to SSL VPNs for particular needs and environments. Table 6-1 provides a high-level comparison of the alternatives. The following summarizes the key points from Section 6:

Table 6-1. Comparison of SSL and Alternatives

Table 6-2 lists the TCP and UDP port numbers and IP protocols associated with SSL VPNs and the alternative VPN protocols described in Section 6. This information may be helpful in configuring other network security devices, such as firewalls and routers, to permit VPN activity to pass through.

Table 6-2. IP Protocols and TCP/UDP Port Numbers for VPN Protocols

This section presents an SSL VPN solution planning and implementation case study. The case study begins by describing a real-world security requirement scenario: protecting network communications between remote users and a main office. The case study then discusses possible solutions for the security requirement and explains why an SSL VPN architecture was selected over the alternatives. The next section of the case study discusses the design of the solution and also provides some details of the implementation of the solution prototype, including examples of configuring the solution using commonly available equipment and software.

The case study is not meant to endorse the use of particular products, nor are any products being recommended over other products. A fictional combination of several common products was chosen so that the case study would demonstrate a variety of solutions. Organizations and individuals should not replicate and deploy the sample entries. They are intended to illustrate the decisions and actions involved in configuring the solutions, not to be deployed as-is into systems.

The scenario described here is connecting remote users to a single main office. A medium-sized organization has a large population of users that work from remote locations once to several days each week. The organization is research-oriented, and many of these users require access to a broad range of internal IT resources to conduct their research. These resources include email, calendar, file sharing services, and secure shell access on a variety of hosts.

The organization already offers remote access services in the form of a host-to-gateway IPsec solution. This works successfully but has required significant IT labor resources to install and support the client software on user hosts. The current solution also does not provide remote access for hosts based in public locations such as hotels and kiosks. The organization is therefore looking to implement a complementary remote access architecture.

The organization specifies its organizational requirements for remote access:

After articulating these requirements, the organization considers its options for remote access:

The organization decides to develop an SSL VPN solution. This solution will complement and not replace the existing IPsec VPN services. It is assumed that some users will stay with the IPsec solution, but others will migrate to SSL VPN over time. The organization purchases a commercial appliance with a support contract to ensure the existence of vendor support.

The organization goes through the process described in Section 4.3 to design the SSL VPN solution. It first designs an access control policy to determine who can access internal resources and under what conditions. The next step is to create an endpoint security policy that enforces access control, usually with host integrity checks. Creating an authentication infrastructure follows, and designing the architecture and deciding on encryption are the last steps.

The organization goes through the four major steps to designing an access control policy that are described in Section 4.3.1:

Table 7-1 summarizes the organization’s access control policy.

Table 7-1. Organization’s Access Control Policy

The organization designs an endpoint security policy to enforce access control. The policy is mainly driven by a prelogin sequence executed by the SSL VPN appliance before a user logs in. This sequence runs host integrity checks that require the host to download and run active content controls. These controls or applets ensure that the host complies with the organization’s endpoint security policy.

The endpoint security policy is based on the access control policy and elaborates further:

The organization has an existing RADIUS authentication infrastructure for multiple resources such as databases and email servers. The SSL VPN appliances use the same RADIUS servers to authenticate users as they login to the SSL VPN portal. The groups that are defined by the access control policy are configured in RADIUS. So most users belong to one large RADIUS group, and the external users granted access to the HR applications are put into another smaller RADIUS group.

The SSL VPN appliances determine this group information from RADIUS so they can dynamically map users into the correct group. For example, a user who is a member of the HR Users’ RADIUS group is only given access to the HR applications.

Users authenticate themselves via two-factor authentication. Each user must type in a password and use a physical token to enter a one-time password generated by the token. Table 7-2 shows the authentication method for each internal resource.

Table 7-2. Organization’s Authentication Methods

For server authentication, the organization purchases an SSL server certificate from a CA whose root certificate is already installed in most common browsers and installs the SSL server certificate on the SSL VPN appliance.

The organization designs an architecture incorporating the SSL VPN appliances within its existing network infrastructure. It performs configuration of the appliances and devises a management policy.

The organization chooses an appliance solution developed by a commercial vendor. Hardware appliances are the most common type of SSL VPN hardware on the market today, and they possess the advantages of being preconfigured and already hardened by the vendor. Furthermore, support is more straightforward because the device configuration is standardized.

The organization adopts an internal SSL VPN approach for device placement. Access to TCP port 443 on the SSL VPN for all external addresses is added to the corporate firewall; no other access rules are added to the firewall. This is similar to the architecture shown in Figure 4-2.

The organization prohibits split tunneling, so the remote access host sends all traffic destined for internal subnets and the rest of the Internet through the VPN tunnel. Traffic destined for machines outside the organization’s perimeter is blocked by the SSL VPN. In this case, attempts to go off the corporate network directly from the user's system are blocked. Some SSL VPNs include hairpin proxies that allow VPN users to leave the network, but only by traversing the SSL VPN gateway which has been set up as a normal outgoing firewall.

The organization has a main headquarters location and several branch offices, but it only deploys SSL VPN appliances at headquarters. All of the organization’s internal IT resources are available at headquarters.

The organization is pursuing a high availability strategy. The VPN appliance supports high availability with an active/passive architecture. Configuration settings are mirrored across both devices, so any configuration change made to the active device is automatically copied to the passive device’s configuration. VPN session information is also mirrored; users do not have to reauthenticate after a device failure, but existing TCP connections are broken and do have to be reestablished.

The management policy for the VPN appliances is consistent with the organization’s security policy. Administrative access is only supported on the appliance’s internal interface and is limited to a small set of IP addresses. Accounts with limited administrative access are created and assigned to different groups, such as one account that can review system logs and another account that can update the host integrity checks to search for recent security updates.

Configuration settings are backed up each week to a central server. The organization also uses a set of appliances for testing and staging. They are configured identically to the live units, and any updates or patches are applied on them first.

The appliances are monitored by the organization’s network management system. The network management system periodically pings the appliances’ IP addresses and polls the appliances’ SNMP management information base (MIB). It compares data from the MIB with known operational values to search for any potential operational issues.

The prelogin sequence requires a remote access host to download and execute active content so the host integrity checks can be performed. The desktop management policies for the organization-managed hosts are configured to permit specific active content controls to run locally.

The organization uses the portal provided by the VPN appliance vendor. It provides some customization such as altering the banner graphics to be consistent with the organization’s logo and colors. It also only displays options that the user is authorized to access. For example, if a user is in the group that is only allowed to view the HR Web sites, only those sites are listed on the user’s portal page.

The organization requires FIPS 140-2 compliance for its SSL VPN solution. As a result, the organization verifies the level of FIPS compliance of the system before purchasing it. The organization configures the SSL VPN to only permit logins from client browsers that use SSL cipher suites with FIPS-approved cryptography. The appliance is also configured to require browsers to support TLS 1.0 for SSL connections.

After the organization designs the SSL VPN solution, it implements and tests a prototype of the design. The prototype is initially configured and tested in a laboratory network and is moved later to a production network so access to actual internal resources can be tested. The laboratory network replicates the addresses of the corporate network, and thus needs to be completely unconnected to the corporate network. The test network includes a firewall with the same configuration as the corporate firewall, and example servers that have the same capabilities and the same addresses as the servers that will be accessed through the SSL VPN.

The organization develops a test plan to evaluate functionality and connectivity. The plan is based on Section 4.3 and includes tests for connectivity, authentication, access control, endpoint security, and client interoperability. Users of multiple operating systems (e.g., Windows, Linux, Macintosh), device types (e.g., laptops, PDAs, smart phones) and Web browsers (e.g., Internet Explorer, Firefox, Mozilla, Safari) must be able to access internal resources from outside the network. If users are using organization-managed hosts, then they should be able to do everything they could do if they were located in their offices. Multiple scenarios such as a user logging in from a public host or a host that has an out of date virus database must be tested. The testers also validate that people with different types of RADIUS credentials only get the expected type of access when they log in during the test.

Different SSL VPNs have different administrative interfaces. Many allow control through Web browsers, while some use custom programs, and still others use old-style command line interfaces (CLI). In this section, a fictitious SSL VPN that has a browser interface is described along with examples of steps that might be taken to implement the rules from the scenario.

The interface has four major sections:

To begin, the administrator needs to configure the addresses of the Ethernet interface on the SSL VPN. The administrator goes to the Ethernet choice in the System menu and sets the address assigned to the SSL VPN on the inside of the corporate network. Because this system is configured inside the existing network, no routing needs to be defined; had this SSL VPN been located outside the firewall or on the DMZ, the administrator would need to specify routing information.

Using the Add User Group choice of the Users menu, the administrator creates a group called “NormalUsers”. In this dialog box, the administrator specifies which authentication mechanisms are used (a password and a physical token) and specifies how the authentication is validated (using the existing RADIUS server). The administrator specifies that participation in the NormalUsers group for the VPN is given to people whom the RADIUS server labels as “User”. They use the Add User Group choice to add a second group, “HROnlyUsers”, but participation in that group is the people the RADIUS server labels as “HR Users”.

The Access menu allows the administrator to define those resources to which the members of each user group have access. Using the Add Access Group command, the administrator creates an access group called “NormalFullAccess” that links “NormalUsers” to all network services, using a network extension program from the SSL VPN. The network extension’s packet filter is set up to block TCP ports 80 and 443 of the addresses of the Web servers that are controlled by the HR department. The administrator also selects only display available resources for this access group.

Next, for users accessing the SSL VPN from equipment that is not owned by the organization, the administrator uses the Add Access Group command to create an access group called “NormalPartialAccess” that links “NormalUsers” only to TCP port 80 of the addresses for the three Web servers that have the corporate calendar, the Web mail system, and the employee phone directory, using a reverse Web proxy, and selects only display available resources. Last, the administrator creates the “HRAccess” group that links “HROnlyUsers”, using a network extension program from the SSL VPN to allow access to only TCP ports 80 and 443 of the addresses of the Web servers that are controlled by the HR department, and selects only display available resources.