Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 6
Page 6 of 7

URL mangling is used to direct user URL requests to the SSL VPN gateway that intermediates the user requests by parsing them to the true destination server address and then forwards the requests to the servers on behalf of the end users. For the web bookmarks on an end user's sign-in page, the bookmarks have been premangled by the SSL VPN gateway. For a URL request that has been input by end users, the URL is mangled by a JavaScript that is downloaded from the SSL VPN gateway at user sign-in time. When the user enters a URL in the SSL VPN sign-in page, the URL mangling routine in the JavaScript is invoked to change the URL properly.

No standards define the format for URL mangling. Mangled URLs can look totally different when handled by different vendors and implementations.

Note that in the previous example, the mangled URL reveals the internal web server address. Because the mangled URL will be displayed in a client browser window and recorded in the browser history file, it might be a security concern for people who don't want to leave the internal web infrastructure information on the client machines, which could be kiosk PCs. One way to resolve this concern is URL obfuscation, also known as URL masking.

Currently, URL obfuscation is a certification requirement by ICSA Labs, yet no standard exists for how URLs should be obfuscated. In general, vendors use a character-encoding table to mask the internal server name and then present the masked mangled URL to the end users.

Content Rewriting

The previous section described URL mangling, which is an important technique in the process by which SSL VPN users access corporate resources using the clientless web access mode. The second important technique is content rewriting.

As a reverse proxy server, the SSL VPN gateway fetches web-based content from an internal web server and performs content rewriting. The main goal of the content rewriting is to change the URL references and Java socket calls so that all users' requests point to the SSL VPN gateway. Also, for Java rewriting, the SSL VPN gateway would need to re-sign with Java bytecode after the rewriting. This is a complicated and resource-intensive process. The content rewriter needs to be able to understand a wide range of complicated web-based objects, such as HTML, JavaScripts, java applets, ActiveX, Flash, and XML and to correctly locate and rewrite the URL references. The loose standard of HTML and web applications makes it more challenging for the content rewriter to properly parse poorly written web contents without breaking the applications.

Server-Side and Client-Side Processing

In the previous example, you saw that the content-rewriting task is carried out at the server side by the SSL VPN gateway. In some occasions, the SSL VPN device merely wraps the web component, and the real content-rewriting task happens at the client-side browser. Client-side processing has the following advantages:

  • For web applications that generate dynamic web content at the client side, it is easier to perform the content rewriting at the client side.

  • Client-side content rewriting is a form of distributed computing that saves a significant amount of system resources on the SSL VPN device.

The SSL VPN gateway first classifies the web content into different types of web objects, such as JavaScripts, ActiveX, Flash, and images. For the web objects that need client-side processing, the SSL VPN gateway's content rewriter simply tags the web object and sends the content to the client browser along with a JavaScript file that has the proper rewriting routines. The client browser then executes the JavaScript routines to perform the final content rewriting before presenting the content to the end user.

Proxy Bypass

Because of the aforementioned complexity of various web applications and content rewriting, it is almost impossible for vendors to supply a content rewriter that works for all web applications. Sometimes, a complicated content rewriter might not interoperate with new web applications because of its intensive processing of the content. As a possible work-around to this situation, some SSL VPN vendors implement a proxy bypass feature as one of the "fail-safe" options. The proxy bypass feature bypasses the default content-rewriting process and instead follows much simpler content-rewriting steps. It mainly looks for the obvious, static links in the page and rewrites them, but leaves the complicated web component alone. In a many cases, this "simpler is better" design philosophy has proven to work better than applying extremely complicated content-rewriting logic on an unknown application.

To differentiate traffic that needs be proxy bypassed and traffic that needs to go through the normal content-rewriting process, either one of the following two schemes is used:

  • Use of high ports: For an internal website that needs to be proxy bypassed, a nonstandard high port is assigned on the SSL VPN gateway. To access the internal website, users connect to https://<SSL_VPN_gateway>:<assigned_high_port>. Upon receiving this request on the predefined high port, the SSL VPN gateway maps the request correspondingly to the internal web server address and applies the bypass-rewriting procedure on the server content.

  • The proxy-bypassed internal websites need to be predefined as user bookmarks. This method is not supported by the client-side JavaScript mangling.

    If a firewall is in front of the SSL VPN gateway, the firewall needs to open additional ports other than TCP/443 to accommodate the proxy bypass.

  • Use of alternative host names of SSL VPN gateway: In this case, the internal web server address is mapped to an alternative host name of the SSL VPN gateway and the user connects to https://<alternative gateway name>.

This method has the advantage of not requiring extra ports to be opened on corporate firewalls. However, it requires more configurations, such as DNS configurations, to allocate additional names of the SSL VPN gateway and extra certificates that map to the alternative host names.

Customizable Rewriting

It is desirable for the content rewriter to have customizable rewriting capability to deal with unexpected situations. Today, SSL VPN vendors have the following customized rewriting techniques at different phases of content rewriting:

  • Preprocessing user interface: This provides administrators with an interface to insert customized content-processing procedures before the content-rewriting engine gets the content. Some examples of the customized processing are cleaning up the HTML content to prepare it for the content rewriter, looking for a specific pattern, and replacing it.

  • Application-specific fine-tuning: For most common web applications, such as Citrix, Outlook Web Access (OWA), and iNotes, the content rewriter has customized rewriting procedures to make sure that it can handle these applications smoothly.

  • Postprocessing user interface: Similar to the preprocessing user interface, the postprocessing interface allows administrators to insert additional content-processing steps after the content-rewriting engine performs the content rewriting.

The preprocessing and postprocessing user interfaces are also important troubleshooting tools that can provide temporary remediation in bug situations.

Selective Rewriting

Normally by default, SSL VPN gateways rewrite all the server content. Some vendors offer a selective rewriting, or "split tunneling," feature in their reverse proxy solution. With this feature configured, administrators can specify a list of domain names that do not require content rewriting. The client browser directly accesses the destination site without having to send the request to the SSL VPN gateway first. For example, the VPN administrator can configure the SSL VPN reverse proxy in such a way that only when end users access internal corporate web resources, will the request be sent to the SSL VPN gateway. For other Internet browsing, the request goes to the Internet site directly without going through the SSL VPN gateway. This is similar to the split tunneling in IPsec VPNs, but not exactly the same. The difference is that in SSL VPN, reverse proxy does not have full control of client traffic as the IPsec client does.

Port-Forwarding Technology

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.

Figure 2-12

SSL VPN Port-Forwarding Operation

The following list describes the process illustrated in Figure 2-12:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Related:
1 2 3 4 5 6 7 Page 6
Page 6 of 7
SD-WAN buyers guide: Key questions to ask vendors (and yourself)