Evaluating SSL-Based VPNs?

Saqib Ali asks: "There are numerous SSL based VPNs available in the market. They all offer same basic functionality, but a varied set of features. I am currently evaluating a few of these of SSL based VPN solutions. Compared to a IPsec based VPN, SSL based VPNs are fairly easy to test and evaluate, since no client installation is required for the SSL based VPNs. One way to evaluate is to test all of my applications against the each product. I am also planning to test support for various browsers. I was wondering if Slashdot readers have some suggestion/ideas on what else to include in my evaluation matrix. Are there any features that are a MUST, or things that I should watch out for while evaluating SSL based VPNs?."

Comments

If you're looking at portal-type VPNs

[darnok]

you want to test scalability. Try hitting it with lots of different "virtual users" simultaneously, and have a few do uploads/downloads of big files if that's functionality you're going to offer.

You'd be surprised how badly some of these solutions scale from a performance perspective. CPU utilisation is the usual culprit, and many of the "off the shelf" solutions don't offer lots of CPU scalability options.

Re:SSLv3, configuration

[AKnightCowboy]

Another important point to check then is how you provision user accounts (in the case of SSLv3). Ask yourself questions such as, how do I give a new user access to the VPN, or what will the procedure be when (not "if") someone has lost/compromised their passwords or other form of credentials? It's a good idea to simulate all this and see if the config interface allows you to do all these tasks easily.

I would imagine with most of them they'd tie into the same authentication mechanisms your current RAS dialup or VPN solution does. Most of them support RADIUS and with RADIUS support you can get almost any kind of hardware token authentication you want. i.e. Point your SSL VPN box at the RADIUS server running on your ACE/Server and you can authenticate SecurID tokens. The good SSL vpns will understand challenge-response protocols as well so you can deal with "next tokencode mode" and "new pin mode" with SecurID cards and such.

If that's too complicated there's also the old standby passwords or SSL certificates, or hell, no authentication at all (acting as a plain SSL reverse web proxy for example).

Re:Test your applictions

[Anonymous Coward]

these products typically only rely on simple TCP streams so they have a higher success rate than IPsec in some network environments.

Ahem. *cough*bullshit*cough*

Anything that uses TCP as a transport is inherently going to have poorer performance than something that uses a non-stream based protocol (such as IPSec, which uses ESP, or even PPTP, which uses GRE.)

This is because of the error-correcting overhead involved with a TCP stream. See this for more information.

Re:Find one that doesn't need a download! :(

[statusbar]

Is it wise to log in to your company's VPN via a public web terminal which may be running all sorts of keypress loggers?

Unless you have a disposable password scheme, this is very dangerous, right?

--jeff++