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

OpenVPN is SSL Based

[echo]

OpenVPN is SSL based, and runs on Linux and Windows.

http://openvpn.sourceforge.net

IPSec is a standard

[mnmn]

The other types are pptp, ssh-based and cipe. IPSec has become a standard between cisco, openbsd, win32, linux and devices like netscreen and solaris.

So why fragment the VPN scene further, and what do you mean no client installation is required. Does it come prebuilt in linux, openbsd, windows 98, qnx, beos?

If clients and servers are available, from how many different vendors, based on which RFCs?

I am curious be cause I never heard of SSL-based VPNs, but I wont contribute to further fragmentation; IPSec has been good to me.

Re:IPSec is a standard

[AvitarX]

There was something about a similar tech on /. a while ago. And from what I could gather it was essentially a JAVA applet that you set the stuff up on.

I don't know how cross platform that would be, or how the permissions would need to look. But I imagine that is what this solution is.

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.

SSLv3, configuration

[ZakMcCracken]

There are basically two kinds of SSL:
* SSL with server-side authentication only, followed by client-side password authentication inside the SSL connection.
* SSL with mutual authentication (client side and server side at the same time).

If you're deploying or ever plan to deploy this VPN with client-side SSL authentication, check support for so-called "SSLv3" or TLS 1.0, versus SSLv2.

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.

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

IPSec tunnels the kitchen sink...

[AKnightCowboy]

The SSL-based "VPN" I'm familiar with is from the company formerly known as Neoteris (Netscreen bought them, and now Juniper looks to be buying Netscreen). Basically the whole idea is that your browser is the only client you need for remote access to your network and for the most part it works great.

The Neoteris stuff in particular provides you with a sort of "secure web portal" to your intranet (they call their product the Instant Virtual Extranet). It's very easy to configure and get setup, supports tons of different authentication mechanisms and the various penetration tests we've had conducted on ours have had it pass without a problem. Underneath it all it's basically a Linux box (right down to a LILO menu letting you select the image to boot, to rollback to an older version, or to perform a factory restore).

We have ours setup with SecurID token based authentication so we can present a secure SSL two-factor authenticated gateway to any of our internal sites without fscking around with the RSA Web Agent software and relying on IIS or Apache for webserver security. I'm not even sure where to start describing it since it has so many features... logging is very detailed down to the URL level, you can access Windows file shares and NFS exports via servlets, etc.

One of the neat features of it though is the secure application manager piece which basically does port forwarding. You can either let users setup their own application forwarding options or present them with a list of preconfigured ones (or both). The Java (or Active-X app.. it's configurable) app even goes so far as to modify the hosts table so users don't have to reconfigure their software. For example, say you want to allow POP access to your internal POP server to authenticated users. Basically when they login this Java app binds to a localhost address like 127.0.0.12 port 110 and then edits the hosts table to point smtp.whatever.com to 127.0.0.12. When you fire off your mail reader and connect to smtp.whatever.com it connects to 127.0.0.12, gets tunneled over the SSL connection and then redirected to the "real" server on the other side. Anyone doing SSH port forwarding should find this familiar, but it's done transparently enough that the end user doesn't have to know how it works. When the session terminates it removes the hosts table entries and cleans itself up by unbinding the ports. We've had good luck with this and laptop users roaming between home and the work LAN without making any changes at all to their applications.

Now, how is this better than IPSec? We don't have to worry about a network layer tunnel being established between some user's "dirty" home workstation and our protected network. There's a lot less chance of something accidently slipping through like a NetBIOS worm because it only allows what you explicitly configure it to allow. This appeals to us mainly because we're interested in it for the RAS replacement functionality. 99% of our users VPN in to our older VPN gateway to check mail or grab a file via Windows file sharing... The Neoteris box totally fits their needs and requires zero software installed on their system for us to worry about supporting. Ever try to make Checkpoint Secure Remote client live nicely with Cisco's VPN software?

By the way, I should point out that SSL VPNs are aimed at real enterprises and not small offices with 20, or even 200 people in them. These boxes costs tens of thousands of dollars to purchase and thousands of dollars in maintenance contract costs per year. These are not meant to replace someone's hacked up OpenBSD VPN gateway with some free IPSec Windows clients they found on the net sort of setup. These are definitely aimed at the bigger corporate environments.

One of our biggest uses has been putting the boxes in front of previously buggy and insecure Windows IIS webservers to offer an additional layer of security. Users don't need some clunky Cisco IPSEC vpn software installed before they can access the web sites in question.. jus

Re:IPSec tunnels the kitchen sink...

[dougdooley]

AKnightCowboy - great posting. You do sound like you work for Neoteris. I'm in Tech Marketing in the former Neoteris, now NetScreen, soon to Juniper organization - and you're about to put me out of a job :)

Seriously, I'm glad our products have worked so well for you. We just release our new code, version 4.0, and there have been some significant improvements and additions. Particularly in the areas of security and access management. Check it out, you'll be pleased with all the new features.

As for looking at the choices, there have been multiple competitive reviews in the SSL-VPN space and NetScreen(Neoteris) has been fortunate enough to receive top honors in the most prestigious reviews:

- NetworkWorld - World Class Award
(#1 out of 7 vendors) Jan 12, 2004
- NetworkComputing - Editor's Choice
(#1 out of 8 vendors) Nov 13, 2003
- PC Magazine - Editor's Choice
(#1 out of 6 vendors) Aug 19, 2003

But to the original question, what are some "essential" things SSL-VPN (or Secure Access gateways) should have?

On the product side, it's really about security controls & access methods. Both are equally important. Scalability is also an issue because you want to be able to grow with your organization's needs.

SECURITY CONTROLS:
- Hardened Appliance/Server with encrypted disks
-- Gov't, Defense, Intelligence agency need FIPS/CC compliant solutions
- 3rd party security audits
- Content Intermediation Engine (blocks DoS/malicious attacks, un-auth user access, provide app security)
- End-Point Security tools
-- Host Checker (scans users for AV, personal firewall, keystroke loggers, trojans, etc.)
-- Cache Cleaner (cleans up session info during and after user logout)
- Access Privilege Management capabilities
-- rules for pre-auth assessment, role restrictions, and resource-based access controls
-- rules can be based on sourceIP, client-side digital certificates info, user-agent, LDAP/RADIUS user and group info, time-of-day, day-of-week, day-of-year, etc.

ACCESS METHODS (no software installation req'd):
1. Clientless Web Access
-- web (static & dynamic content)
-- web-apps (complex content: JavaScript, VBScript, scriptable ActiveX, Java Applets, Flash, etc.)
-- email (OWA, iNotes, Webmail, POP/IMAP, SMTP)
-- terminal session (telnet/ssh)
-- desktop sharing (ICA, RDP, VNC)
2. Client/Server support
-- Java version - static port apps
-- Windows version - process name, dynamic port, and/or ip range: port range
3. Network-based support
-- full network tunnel (TCP, UDP, ICMP - all traffic)
-- greater security concerns but greatest level of resource access

SCALABILITY/PERFORMANCE:
- Configuration clustering (minimum)
- Session syncronization clustering (very good)
- Hot standby (Active/Passive) clustering
- Full Active/Active clustering
- Local clustering (same subnet)
- Multi-Site clustering (across networks)
- Mulit-Unit clustering (3 or more)
- Support up to 10,000 concurrent user sessions
- Hardware-based SSL offloading
- Hardware-based Compression (improve response-time on slow connections)

I'm just scratching the surface. There's so much to cover but those are some of the essential things to look for.

Good Luck -
Doug

Test your applictions

[mafmaf]

The most important thing is to test the applications you want to access through it. This area may be a minefield since this type of VPN usually only offers limited connectivity. Some applications may use dynamic ports, expect reverse connections, or exhibit other strange behaviours.

Also check if the product supports the authentication method you want to use. This should normally not be a problem but since authentication systems may cost quite a lot it is a good idea to check it out.

Another thing to look at is reliability. How stable is the box, what happens if the box breaks? Can you connect multiple boxes in a cluster?

Also do not stare blindly at the SSL protocol but rather focus on functionality. There are other products which have similar functionality but builds on different protocols. For example AppGate which uses SSH as the basic protocol (disclaimer: I work for AppGate:-).

The most common functionalities people tend to look at are:

• The ability to have fine grained access control, down to the user level.
• Ease of deployment
• Ease of use
• "Network ruggedness" these products typically only rely on simple TCP streams so they have a higher success rate than IPsec in some network environments.

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

[matt_wilts]

As I write this, I'm sitting at an Internet Cafe in London Heathrow aiport. I just tried to log on to our company SSL VPN/portal which is based on Citrix's Nfuse product.

The reason I'm now on Slashdot is that the portal needs to download a small applet onto the desktop, I believe it's Citrix's ICA client - and the browser here is locked down so tight I can't run the app! So, buyer beware!!

Matt

ssl review at nwfusion

[Anonymous Coward]

Hi,

It has all been done for you. Read:

http://www.nwfusion.com/reviews/2004/0112revmain .h tml

Regards,

Paul

Strength of encryption versus speed.

[gedeco]

Depending of the algorithm in use you will have a slow or fast VPN in use.

For instance IPSEC

- you could have 512 keys (breakable with a lot of effort) or 2048 key pair encryption.
Defenitly if the 512 key pair is in use it will be faster.

I make a balance between speed and the weight of data you need to protect.

To protect my financial data, I would use a good tight VPN.

For instance @ home, I use CIPE for wireless VPN into my server. Reliable and speed are the keywords. I don't care, I someone is capable to decrypt my most favorite websites etc...(after a few weeks). I don't share confidential info on it.
Just need to protect my wireless network from script kiddies using tools for cracking WEP.

Depending on the use, you should use a type of VPN. Just like you made the difference between a truck and a car.

Geert

Just Remember:

[mosel-saar-ruwer]

A firewall/tunnel/authentication scheme/protocol/whatever is only as good as its ASN.1 Buffer Underflows.

Don't laugh - have you strcpy()'ed today?

Packet Sniffer

[Dolemite_the_Wiz]

I know this sounds dumb but make sure when you're testing the product that the transactions are indeed secured. I don't know how many times I've been called into a lab to find flaws in people's tests to find out that they didn't even check to see if transactions were secure.

Dolemite
______________________

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++