- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Page 6 of 6
Clientless web access supports only a small set of corporate business applications that already have a web interface or can be easily webified. To be a complete remote access VPN solution, SSL VPN–based solutions need to be able to support other types of applications. The port-forwarding client solves part of the problems.
The SSL VPN port-forwarding client is a client-side agent that intercepts specific application traffic and redirects the traffic to the SSL VPN gateway through the established SSL connection. The port-forwarding client is normally a thin client, that is, a small application or applet that is smaller than 100 KB.
SSL VPN vendors use different techniques to implement the port-forwarding function, for example, a Java applet, ActiveX control, Windows Layered Service Provider (LSP), or Windows Transport Data Interface (TDI). The most popular technique is the Java applet-based port-forwarding client. Compared to other Windows-based techniques, Java applet–based port forwarding supports both Windows and non-Windows systems, such as Linux and Mac OS, as long as the client system supports Java.
Figure 2-12 illustrates how a Java applet–based port-forwarding client works.
SSL VPN Port-Forwarding Operation
The following list describes the process illustrated in Figure 2-12:
The end user launches a web browser to connect to the SSL VPN gateway. After the user signs in, the user clicks to launch the port-forwarding client.
The client machine downloads and runs the Java applet–based port-forwarding client. The port forwarding can be configured in the following two ways:
— For each client application that connects to an internal application server, a local loopback IP address and port are predefined. For example, for a Telnet application to internal server 10.1.1.1, the port forwarding client maps it to loop back IP 127.0.0.10 and port 6500. Instead of running Telnet to 10.1.1.1, the end user enters telnet 127.0.0.10 6500 to telnet to 127.0.0.10 on port 6500. This sends the traffic to the port-forwarding client that is listening on this IP address and port. The port-forwarding client then encapsulates the client Telnet traffic and forwards it to the SSL VPN gateway using an established SSL connection. The SSL VPN gateway then unpacks the traffic and forwards the Telnet request to the internal server at 10.1.1.1.
— With the method described in the previous point, end users have to change the application setting every time to connect to the assigned loopback IP address and port—an operation they find inconvenient.
To solve the problem, a port-forwarding configuration can specify the host name of the internal application server. For example, the Cisco port-forwarding client first backs up the Hosts file on the client machine, and then adds an entry in the Hosts file to map the internal server host name to the assigned loopback IP address. Use the previous example to see how this works. For the internal server 10.1.1.1 with host name router.company.com, the port-forwarding client first backs up the client machine's Hosts file to Hosts.webvpn, and then adds the following entry to the Hosts file: 127.0.0.10 router.company.com. The end user in this case would just enter telnet router.company.com. To perform the DNS lookup, the client machine looks up the modified Hosts file and then sends the Telnet traffic to the loopback address on which the port-forwarding client is listening.
With this method, the end users do not have to change the client application setting every time. However, to modify the Hosts file, the end user would need certain user privileges. For example, Linux users would normally require root-level privilege to be able to change the Hosts file.
Users launch a client application in the previous steps. The port-forwarding client port-forwards the client application traffic to the SSL VPN gateway under the protection of the established SSL connection.
The SSL VPN gateway unwraps the traffic and forwards the client application traffic to the internal application server, and relays the subsequent communication between the client and the server.
The end user finishes the application and logs out. The port-forwarding client restores the client machine's Hosts file. The port-forwarding client can either be uninstalled upon user logout or stay on the client machine.
As you can see from previous description, the Java applet–based port-forwarding technique has the following characteristics:
For each TCP flow, a port-forwarding entry needs to be specifically configured to map to a local loopback address and TCP port.
The application needs to be initiated from the client side.
Java applet–based port-forwarding clients normally support only simple client-server-based, single-channel TCP applications, such as Telnet, SMTP, POP3, and Windows remote desktop service. For applications that use multiple TCP ports or dynamic TCP ports, such as active FTP and Microsoft Exchange Protocol, Java applet–based port forwarding is not a good choice.
Some Windows-based port-forwarding clients support some multichannel TCP applications and applications that use dynamic ports. They can only track and port-forward traffic from specific Windows processes or to specific destination addresses. Although this allows the port-forwarding clients to support more applications, they are limited to Windows-based client computers and can require end users to have administrative privileges. The Smart Tunnel Access from the Cisco ASA SSL VPN appliance is one example.
Compared to clientless web access, the port-forwarding technology supports more applications but with less granular access control. The level of access control is still much more specific than the traditional IPsec clients, which provide full network-layer access to end users by default. This access and control trade-off makes port-forwarding technology a good choice for business partner access scenarios, where partners can access only specific application resources on the corporate network.
To use the port-forwarding techniques, users must have client applications installed and configured to point to the local loopback address or the internal server address. You cannot assume that the client computers have these applications available. For some commonly used simple remote control applications, such as Windows terminal service, Citrix terminal service, VNC, Telnet, and SSH, some SSL VPN vendors provide extra convenience by delivering the remote control applications to the client computer.
We use Windows terminal service as an example of how this feature works. End users first log in to the SSL VPN; then they click the bookmark to launch the terminal service application. The client browser then downloads a package, which is often an ActiveX control or a Java applet, from the SSL VPN gateway and installs the package on the client PC. This package contains a customized Windows Remote Desktop Protocol (RDP) client, which enables the user to run a Windows terminal service connection to a corporate internal Windows terminal server. Also, in this case, the end user does not have to configure this RDP client. The traffic is automatically forwarded to the SSL gateway that intermediates the traffic between the RDP client and internal terminal server.
Traditional clientless web access and port-forwarding access do not satisfy the needs of power users and telecommuters who run VPNs on corporate-owned machines and like to have full access to the corporate resources. The IPsec VPN is a better fit to provide full network-layer access to the VPN users. Organizations that already have a remote access IPsec VPN can use the existing VPN solution to provide network-layer access and clientless SSL VPN for application-level VPN access. Today, most SSL VPN solutions also provide a tunnel client option for companies that have a greenfield remote access VPN deployment.
Again, unlike IPsec VPNs, SSL VPN tunnel clients have no standards, and different vendors use various tunneling technologies. However they do share some common characteristics:
The SSL VPN tunnel client can be downloaded on the fly from the SSL VPN gateway and installed on the users' computers. Normally, deliveries are through Java or ActiveX using established SSL connections. This way, there is no need to preinstall the VPN clients, as required by IPsec VPN solutions.
For installation, in most cases, tunnel clients require users to have administrative privileges.
The SSL VPN tunnel clients normally function in user space rather than kernel space. Because of this, the VPN users do not need to reboot after the VPN client is installed.
The tunnel client often installs a logic adapter (for example, a PPP adapter or a virtual adapter) on the user machine and gets an IP address assigned from an internal IP address pool. After the tunnel client captures and encapsulates the client traffic using the logic adapter, it transports the packets to the SSL VPN gateway using the established SSL connections.
Because the SSL VPN tunnel clients can be distributed and installed on the fly during the SSL VPN sessions, they save the IT management cost that would have been required by current IPsec VPN solutions.
Most current SSL VPN tunnel clients transport packets using SSL. The DTLS section covered the performance issue of this approach to support real-time applications. SSL VPN vendors are looking for solutions to resolve these issues. Currently a few methods have been adopted:
Advanced compression techniques to improve the performance.
IPsec transport. In this case, the SSL VPN tunnel client is delivered using SSL, but the data transport uses IPsec technology.
DTLS or alternative UDP mechanisms as data transport mechanisms.
This chapter covered the SSL and SSL VPN technologies in detail. The chapter started with basic requirements of a secure VPN and discussed how to use various cryptographic algorithms and applications to achieve these requirements. The piecing together of these technologies followed, with a discussion of the workings and implementations of the SSL/TLS protocol, which is the secure transportation base for an SSL VPN solution. The chapter concluded with a discussion of the SSL VPN and various remote access technologies that are deployed to build an SSL VPN solution. In summary, this chapter helps you to understand how SSL VPNs deliver secure communications and application access from a technology standpoint. With this understanding, you are well prepared to move on to the design and deployment of SSL VPN solutions.
SSL and TLS, Designing and Building Secure Systems, Eric Rescorla, ISBN 0-201-61589-3.
Applied Cryptography, Bruce Schneier, ISBN 0-471-12845-7.
Network Security, Private Communication in a Public World, Charlie Kaufman, Radia Perlman, Mike Speciner, ISBN 0-13-061466-1.
Network Security Principles and Practices, Saadat Malik, ISBN 1-58705-119-2.
RSA laboratories crypto FAQ, http://www.rsasecurity.com/rsalabs/node.asp?id=2152.
RFC 2246, "The TLS Protocol."
The SSL Protocol, version 3.0, http://wp.netscape.com/eng/ssl3/ssl-toc.html.
RFC 2818, "HTTP over TLS."
PKCS standards, http://www.rsasecurity.com/rsalabs/pkcs.
RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile."
RFC 2405, "The ESP DEC-CBC Algorithm with Explicit IV."
RC4 information at wikipedia, http://en.wikipedia.org/wiki/RC4.
The Diffie-Hellman introduction at wikipedia, http://en.wikipedia.org/wiki/Diffie-Hellman.
The RSA introduction at wikipedia, http://en.wikipedia.org/wiki/RSA.
The DSA introduction at wikipedia, http://en.wikipedia.org/wiki/Digital_Signature_ Algorithm.
Read more about lans & wans in Network World's LANs & WANs section.