SSL VPNs: Complexity to make your life simpler

The conventional wisdom is that Secure Sockets Layer VPNs are simple. It’s a lie. They are enormously complex – vendors just make it look simple to the user.

The conventional wisdom is that Secure Sockets Layer VPNs are simple. It’s a lie. They are enormously complex – vendors just make it look simple to the user. A recent project gave me a chance to dig deeply into this important area, and I was impressed by the sophistication of some implementations – and corresponding gaps in others.

Ostensibly, the hybrid SSL VPN came about to provide the “tunnel-across-the-Internet” features of traditional VPNs sans the need for the installation of client VPN software and the often nightmarishly difficult configuration thereof.

Paradoxically, though, the best SSL VPN offerings are strongly “anti-VPN.” This is because the seamless connection between far-flung computers into one logical network, which VPN technology provides effectively, can turn your network into a sieve when the remote computer is either quasi-public, used by multiple people or in any way out of corporate control, which, by definition, it is.

The difficulty in installing and configuring stand-alone VPN software often prevented such computers from being involved, but today it is quite easy, for example, to create a VPN connection from any Windows XP machine to which you happen to have access. Within a few minutes, you can be browsing your intranet, accessing server shares – and perhaps inadvertently exposing corporate data to unauthorized distribution or misuse.

SSL VPNs are “clientless,” meaning that one need not install or prepare the client machine used for the session. All the required software is downloaded at session initiation as ActiveX control or a Java applet (depending on whether you are running a Microsoft browser or not). Thus, any machine in an airport kiosk or hotel lobby can instantly allow you to access corporate resources – and if you’ve picked the wrong SSL VPN solution – just as quickly become a gold mine for people up to no good.

Where often we find situations in which comparing data sheets from different vendors results ultimately in identifying, as the old saying goes, “distinctions without a difference,” that is not the case with SSL VPNs. To the contrary, vendor data sheets tend to be a little too high-level, thus hiding, intentionally or inadvertently, important implementation differences that can mean the difference between a secure or a Swiss-cheese network.

I’d bet that every one of the dozens of SSL VPN vendors says it provides a secure environment for browsing intranet or Internet Web sites from the SSL VPN client. A spot check of, say, the browser history on the client might lead you to believe that the product you are considering is safe. But there’s more to it than that.

What about any cookies picked up during the session? We found that several major players leave them behind. While many products will delete any e-mail attachments that you’ve downloaded and read, some will fail to delete the files you downloaded from the Internet or your intranet.

If you clicked “yes” on the auto-complete password prompt, you’d better change your password immediately, as several major SSL VPN providers allow that information to remain on the machine after you log off your session. I could go on.

Just in the areas of endpoint security and access control policy, we’ve identified more than two dozen discrete tests that can be applied to evaluating features and functions of SSL VPNs. Click here for details.

Follow ours or develop your own – just don’t deploy unless you’ve put your network under the microscope.