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

Suggestion

[slubberdegullion]

What the hell is a VPN

Re:Suggestion

[JerkBoB]

Vacuous Post, Noob.

OpenVPN is SSL Based

[echo]

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

http://openvpn.sourceforge.net

Re:OpenVPN is SSL Based

[grimace1969]

Besides running on a bunch of platforms, the nice thing about OpenVPN is that it isn't browser based like a lot of SSL VPNs, it creates a tunnel (with either a tun or tap device, depending on configuration). OpenVPN is a great option, if ease of use is a factor. The Windows install is a breeze (which is important if you have a lot of "Road Warriors"). It basically leverages the high availability of SSL technology to create a secure and easy to set up VPN. It does NAT traversal, and pretty much anything else FreeSWAN does, but like I said it is much easier to setup.

--G

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

Re:IPSec tunnels the kitchen sink...

[-tji]

It is inaccurate and misleading to say "IPSec tunnels the kitchen sink...". Any decent IPSec client turns OFF IP forwarding, so it's not going to tunnel anything from the "dirty LAN". Some VPN Clients also provide a client firewall, check the OS for security/integrity, and integrate with other apps like anti-virus. If all those security checks don't pass, they are not allowed to connect to the VPN. That's pretty hard to replicate with a "clientless SSL VPN".

Also, on the VPN server that it connects to, the firewall/vpn device controls exactly what is allowed to pass. So, it's not like it opens up some big hole into a network, it only allows what the admin wants.

The IPSec clients also have the advantage of using certificates for strong authentication. Using SecurID, like your company, is a wise precaution (though the security of SecurID vs certificates/smart cards could be debated). But, I have seen companies that provide very broad access to servers in their network based only on a password.. That's scary considering the weak passwords that Joe Average User often picks, or someone installing a key-logger on a public terminal.

I think SSL VPN has its place, but the security policy, authentication methods, and decisions about what is allowable to access via SSL is extremely important.

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.

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.

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

Re:ssl review at nwfusion

[cybernautix]

No it hasn't. PPPD-over-stunnel is blatantly missing. The review is skewed toward opportunistic VPNs and ignores *nix gateway-to-gateway VPNs completely.

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

Re:Strength of encryption versus speed.

[Anonymous Coward]

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.

Not so, most IPsec based VPNs only use asymetric encrpytion for the exchange of symetric keys so your choice for key lengths are limited to what DES, 3DES, and AES have to offer. The symetric keys are used for the vast majority of the traffic.

Re:Strength of encryption versus speed.

[-tji]

You are confusing the key exchange with the data encryption.

To set up an IPSec tunnel, IKE (Internet Key Exchange) happens first, to securely establish all the necessary session and keying information. This typically uses 1024 bit RSA, and most devices also support 1536 bits. As a result of the IKE process, both sides have agreed on all the IPSec session parameters and computed a session key.

The session key is used by the negotiated encryption algorithm {DES, 3DES, AES-128, AES-256, RC4, etc.} to secure the communications. The performance will depend somewhat on which of these ciphers is used.. e.g. AES-128 will be faster than 3DES while offering similar security. But this symmetric encryption is MUCH faster than the Public Key crypto you referenced.

Re:Strength of encryption versus speed.

[gedeco]

You are right. I just tought it could be usefull to consider encryption strenght versus the use of the information and the speed. 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?

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

[martums]

I was going to post a blatent plug for Citrix's NFuse Classic, because we've been using it at work for over a year and it's been pretty well received, (in fact, using MetaFrame as a whole has allowed us to continue to use legacy hardware which would just get scrapped or recycled anyway, which means more terminals pointed to speedy terminal servers, and more busy users, fewer bucks on new hardware).

Of course, using NFuse from a locked-down public terminal is a hindrance. (Darn inconveient, too, I reckon). Did the public terminal have any Java runtime installed? There's a Citrix ICA Java client, but I think you'd have to run a Java applet from a web page for the current one (7.x). We don't use the applet on any of our web sites. I'm curious to take a crack at it now. Although, few if any of our users are likely to try it from a public temrinal and read the site to work-around, (they're more than likely to get frustrated and walk away logged-in).

more about the 7.x Citrix Java client here

Capabilities?

[phorm]

It doesn't really say on the page, but I'm wondering just what it can tunnel?

I know a lot of people whom play LAN games are looking for a good VPN server/client which is easily NAT'able - to be used for playing LAN (often using IPX/SPX protocol) games or using LAN software as if two remote computers are within the same network.

Anyone tried this for those purposes?

So far, I've played a lot with GIT for such purposes, but it doesn't do exactly what I want, and doesn't seem overly secure (though possibly faster than VPN)

Re:Capabilities?

[Anonymous Coward]

It can tunnel at the IP level (TCP, UDP, etc.), or the ethernet level (so you can bridge two ethernet segments - both computers will be in the same broadcast domain, and IPX/SPX should work fine). It doesn't require any kernel modules either, except a very generic tunneling driver.

I've run a UDP-based tunnel between one computer which was behind a crappy Linksys router using NAT (it wouldn't route anything besides TCP or UDP, even if I made my computer the DMZ host - I initially wanted to use IPv6), and another computer behind a restrictive university firewall which didn't allow incoming connections.

I set up the proper UDP port forwarding on the router, initiated the tunnel from the university side, and turned keep-alive on. I didn't try gaming, but the computers were basically in the same network. Everything was forwarded, including broadcast packets.

It's pretty flexible and well-documented. According to the documentation, you can even configure it so the tunnel stays up when one person's dynamic IP changes.

Re:Capabilities?

[echo]

It is a regular point to point link, so it can tunnel any TCP/IP stuff.
In fact, if you set it up to use ethertap, it tunnels ethernet frames, and you can tunnel IPX, NetBeui, whatever strange things you want, even ARP.

Re:Capabilities?

[NoMoreNicksLeft]

It can do ethernet bridging. So just about anything, is the answer to your question.

I emailed the author a few months back, begging for SOCKS5 support. He said sorry, I have no plans for it. Politely. But damned if the latest release doesn't support socks. I'm nominating him for networking godhood.

And I think for practical purposes, it's as secure as anything out there. Certainly easier to use than freeswan...

Be sure to include stunne;-to-stunnel

[cybernautix]

It's not apparent from your post, but if you are evaluating gateway-to-gateway VPNs using *nix systems, I'm *really* interested to hear how PPPD-over-stunnel measures up. It seems to simple in concept, but how is the CPU load?

Has anyone else benchmarked PPPD/stunnel vs. PoPTop or FreeS/WAN?

VPE

[HeelToe]

What about VPE? It has some niche features that could make it the right choice for certain applications.

http://freshmeat.net/projects/vpe/

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! :(

[Anonymous Coward]

You can code the connection to fall back to the JAVA client automatically should the ICA client fail to connect. Designed for those special Kiosk moments.

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

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

[martums]

Excellent point. I wonder how many enterprises have such a system in place for their users? That would seem almost impossible for a small to medium business to implement. Disposable passwords almost seem exclusive to the realm of the large enterprise.