SSL VPNs (2005)

Not long ago, SSL VPN products comprised quite specific templates for known applications such as extending messaging systems like Microsoft Exchange, or thin client front-ends like Citrix. Endpoint security was clumsy, when it was present at all, and tunneling support left much to be desired.

But in the past couple of SSL VPN tests, we have seen marked improvements industry-wide. Part of this is down to much better web support from the backend applications, making the SSL front-end much easier to integrate, but a large part seems to be simply a recognition by vendors (and customers) of what the core features need to be, and how they should be addressed.

As a result, we were again impressed by the technology on offer by the participating vendors. The products were much more consistent than they have been before, with the basics covered well and most offering enterprise options for high availability, and centralized policy management.

We tested them for suitability in large enterprises, with internal web applications, thin clients running legacy systems, and Exchange email servers. With hypothetical users logging in from home, from the road and from public internet systems, we wanted to control access based on the user's credentials as well as location. So we looked closely at the granularity of authentication schemes, with an eye for failure states and how they could be accommodated.

However, there were still areas where some outperformed others, especially in scalability, support for multiple platforms, delegated admin, and ease of management.

In most cases, we found the test products supported a wide range of authentication techniques, covering Radius, SecurID, LDAP, local usernames, and NTLM. Some went much further, but the core was consistent across the test.

Application support was also better than we expected. Few of the products offered more than basic proxying and forwarding, but we had no problem extending web applications to remote users.

Endpoint security is one of the grails of remote access. Two needs are paramount. First is controlling the initial state of the client. Is it secure? Does it have AV software installed? Is the patch level acceptable? Second is the final state of the system – cleaning the cache, removing temporary files.

In general, we found endpoint agents would perform adequately under ideal conditions, but poorly otherwise. It is usually just too easy for a user to break out of the sandbox. If you really want fully enclosed control over the remote desktop, you might turn instead to Citrix, Microsoft Terminal Services or similar thin-client options. Some of the agents were simply obstructive to the end user, which we feel pushes the security compromise a step too far.

Tunneling support under SSL is much better supported nowadays. Setting up SSL/TLS tunnels is straying into IPsec territory, and vendors have had some tough nuts to crack with protocol problems, performance and split tunneling (where certain traffic is redirected via the VPN, but the rest sent across the default gateway). Some imaginative workarounds have been seen to tackle these problems in the past, but most now simply rely on the locally-residing agent to do the client setup.

Because the feature set of these products has advanced so much, it was inevitable the role of the client software would also grow. From pure browser-based SSL front-ends, every product now uses an agent for endpoint control and tunneling at a minimum. As a result, the claims of "client-less" SSL VPNs are now outright false, although you could argue that the browser actually counts as a client.

But the important factor is that client software implies a degree of reliance on the local system, so we were disappointed to see that many products limited feature support to Windows and Internet Explorer. Organizations with Macs or deployments of alternative browsers may have to think carefully about their choice of SSL VPN. IPsec proponents would be quick to point out that these platforms have seamless IPsec clients today, but we are confident that as vendors support Java clients over ActiveX controls, these concerns can be addressed.

Choosing an SSL VPN used to mean carefully deciding which applications you wanted to extend, and then trying to find a product to support them. This has evolved to checking client support and integration into endpoint security policies, but the industry has achieved real depth of application support. IPsec is still the best tool for site-to-site communication, but extending applications to remote users via SSL can be a quick win for any administrator.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.