SSL VPN gateways
NetScreen, Nokia top the growing field of products that target simplified secure remote access
Security with ease of use is the promise of Secure Sockets Layer VPNs. In our test of seven SSL VPN gateways - from AEP, F5 Networks, NetScreen Technologies, Netilla, Nokia, Symantec and Whale Communications - we assessed how well each is equipped to provide secure remote access to corporate applications.
The good news is that several products are well-suited for enterprise use. Our World Class award goes to NetScreen for its outstanding application support, good access control mechanisms and overall interoperability. Nokia, Symantec and F5 all make our short list because of the broad spectrum of application support they offer.
Our basic assumption for testing SSL VPNs is that they must fit into existing networks and application environments (see How we did it ).
To that end, we tested interoperability of each device against 20 enterprise applications.
We tested these products from the point of view of network and security professionals; focusing heavily on access control and security features.
In terms of features, we evaluated auditing, accounting, reporting and logging tools. We also tested client integrity scanners, which help ensure that virus scanners and firewall features are up to date.
Applications are everything
The biggest difference between SSL VPNs and traditional IP Security remote access VPNs is that the IPSec standard requires installation of client code on the end user's system, while SSL VPNs focus on making applications available through any Web browser.
In some cases, SSL VPNs must provide secure access to the applications that are served up as static Web pages on HTTP servers, but taking Web traffic in one port and sending it out another is not where these products bring their greatest value. SSL VPNs are deployed for bigger, more compelling reasons such as complex application translation of Web-to-e-mail servers, corporate directory and calendar systems, e-commerce applications, file sharing, and remote system management.
When it comes to proxying and application translation (see "SSL terms and conditions"), we found big differences between products (see graphic, below). AEP and Whale were the weakest in this area, supporting the smallest number of application translators and proxies. Nokia was the only one of the stronger products to support application translation for FTP, Network File System (NFS) and Microsoft file servers. With F5, Netscreen and Symantec each offering a subset of the three. Netilla was the only offering to include translation for both Windows Terminal Services and a extensive array of terminal emulators, including telnet, Secure Shell (SSH) and IBM 3270. We tested all but the IBM emulations and had good results. F5 and NetScreen also included terminal emulator support for telnet and SSH, but they struck out because their emulators didn't work more than 25% of the time.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Because the products we tested offer such a variety of options, for you to pick the right gateway for your network you'll need a firm understanding of which applications you need translation for and be able to rank them in terms of importance. For example, Symantec and F5 gateways include e-mail application translation - so users can read and send mail via an application running on the gateway. Unfortunately, Symantec's built-in Web mail feature doesn't work if you have a lot of mail in your mailbox.
Even SSL VPN gateways that don't support a built-in Web mail tool would let you connect to a corporate messaging application, such as Microsoft Outlook Web Access, IBM's iNotes or the open source SquirrelMail. As our interoperability testing indicates, these rich applications have their own problems. So you might be left with the difficult choice of a rich Web-based messaging application that not everyone can use, or a less powerful and feature-poor Web mail system that is friendlier to unusual or older browsers.
Some applications cannot be translated, and SSL VPN gateways have two mechanisms for getting direct access into the network: port forwarding and network extension. Port forwarding lets you protect well-behaved applications on known servers, and network extension gives broader access via tunneling to an entire network.
The further down this direct access path you go, though, the more complicated and risky your SSL VPN deployment will be. To accomplish port forwarding or network extension, the SSL VPN gateway must push out software to the end user's workstation. This raises browser compatibility issues, operating system problems and security concerns. For example, a user sitting in front of Microsoft's Internet Explorer with browser security set to "high" would not be able to use any of these features. Unfortunately, permissions to lower browser security are not always available.
A second problem with port forwarding and network extension is security. One promoted strength of SSL VPNs is the ability to look into the application layer and give detailed access control to the network manager. When port forwarding and network extension come into play, SSL VPNs no longer offer such access control to applications because they are no longer aware of the underlying application. Rules down to the URL level, one of the characteristics of SSL VPN technology, aren't available when using network extension and port forwarding.
| ||||||||||||||||||||||||||||||||||||||||||||||||
All the SSL gateways we looked at except for AEP and Netilla provide some port-forwarding functionality (see graphic, above). However, port forwarding is not sufficient for all applications. A good example is FTP, which uses IP addresses and port numbers within the protocol to identify a server and client socket for data transfer. Port forwarding won't work with all FTP clients, unless the SSL VPN gateway knows that it is forwarding FTP traffic and rewrites IP addresses within the traffic.
Application layer gateways (ALG) could add this kind of knowledge to port forwarding, and they are common in real firewalls. SSL VPN gateway vendors made an effort to add ALGs to their port forwarding to two areas: in e-mail, specifically MAPI (for Exchange clients) and Notes smarts, which ships with the NetScreen, Nokia and Symantec gateways; and in remote desktop clients using Citrix terminal services, which ships with NetScreen and Nokia gateways.
Instead of making port forwarding smarter with ALGs, many SSL VPN gateway products support network extension: connection of the end user's remote system to the network behind the SSL VPN gateway. In the group we looked at, all but Nokia and Whale include network extension technology.
E-mail is arguably the most popular SSL gateway feature because our testing found yet another way that some products support e-mail. AEP, NetScreen, Nokia and Symantec all include proxies for the standard mail protocols Simple Mail Transfer Protocol (SMTP), Post Office Protocol and Internet Message Access Protocol. The idea is that you'll point your POP or IMAP client mail application at the SSL VPN gateway, encrypting from client to the gateway using standard POP-over-SSL, IMAP-over-SSL and SMTP-over-SSL, thus adding security to the mail transactions. This technique also can add SSL to older mail servers or give access to servers that are on private address space. The benefit of using this technique is compatibility across all modern platforms and modern e-mail clients without requiring special operating system access the way port forwarding and network extension do.
Interoperability problems
Web applications are frightening things to security vendors. The extreme generosity of browsers in accepting and displaying incomplete Web pages, incorrect JavaScript and illegible Java has led to a generation of applications that make little sense from a software development point of view - but seem to work. Building an SSL VPN gateway to handle these applications is an unenviable task. We tested 20 applications with seven browser/platform combinations and found wide variation in what works (see graphic, below).
|
One goal for this review was to test the vendors' claims that these products are easier to set up and use than IPSec VPNs. Along the way, we saw a lot of backpedaling: These products are easier for the end user to use, but sometimes harder for the network manager to maintain. In some cases, we know that updating client software, clicking hidden or obscure feature boxes, and a hefty dose of quality technical support could have solved the problems we saw. But we wanted to see how well the average network or security manager - not a Web application programmer - would do. We ruled out changes to client systems as unacceptable and not in the spirit of SSL VPNs' goal of security with ease of use.
We started with five basic Web applications, some of which included basic JavaScript. The only vendor to support five applications on seven platforms was Nokia, although F5 and NetScreen only missed one each, while Whale and Symantec missed three or less. AEP got bad marks on two of the applications, one with JavaScript and the other going to an SSL-protected Web server in the back - AEP doesn't support back-end servers with SSL, although everyone else does. Netilla also lost points for losing graphics. Although every page eventually loaded correctly if we pressed "Reload" enough, we gave Netilla only half-credit on applications that missed a lot of graphics the first time through.
Next up in our testing were the two big mail applications, Outlook Web Access 2003 and iNotes, versions 6.0 and 6.5. Here, Nokia came closest to getting it right, with AEP and Symantec next in line (although Symantec did manage to crash our Netscape browser when feeding it iNotes). The newness of Outlook 2003 threw a bit of a curve at our SSL gateways. However, we argue that a big question for SSL VPNs is whether these products act like appliances, independent of the software behind them, or will they put you on a treadmill keeping things up to date?
It's pretty clear that vendors don't expect these gateways to work without some tuning. We restricted ourselves to out-of-the-box configuration, but most of the systems had a number of obscure knobs and adjustments that were added to help increase compatibility. Netilla is a good example. When defining an application, for example, you can select either "Fast HTML Translation" or "Full HTML Translation." The only documentation for how to choose one or the other is the ambigious note: "Fast is appropriate for most pages." As another example, Whale devotes 75 pages of documentation to fine-tuning the handling of applications .
Our third series of tests used three Web-based applications that included Java and different types of Flash. The results were dismal. F5, NetScreen and Symantec managed to each get one of the applications working some of the time. AEP, Netilla, Nokia and Whale scored zero in this phase. The lesson is simple: Advanced applications with tools such as Java and Flash just aren't going to work easily through SSL VPN gateways, not without using techniques such as port forwarding or network extension.