Features Download
From: Matthew Grooms <mgrooms-7J06MVNuoZVeoWH0uzbU5w <at> public.gmane.org>
Subject: Re: AW: SSL VPN
Newsgroups: gmane.comp.security.firewalls.pfsense.support
Date: Wednesday 9th July 2008 00:54:55 UTC (over 10 years ago)
digger wrote:
> It would be great if there were a clientless SSL VPN product like 
> SSL-Explorer that used a java applet for the client side but had the 
> server written in something like C that would be far less resource 
> intensive on the server and would run on pfsense. Does anyone know of 
> such a beast?

The whole idea of clientless VPN is a complete marketing ploy. You can't 
redirect traffic passing through the kernel from user land without 
installing some sort of kernel mode driver and key management software 
on a computer. Java is an application framework and it doesn't offer any 
of this functionality natively. Sure, the key exchange and GUI parts may 
run in java, but then you have a 15MB JRE dependency for 5MBs worth of 
applications. How thin is that? When you read between the lines of the 
marketing hype, companies usually mean easy web deployment of the client 
software via a browser when they say 'clientless' solution. That doesn't 
mean there isn't sophisticated client software involved.

One of the worst remote access implementations I have ever seen was a 
clientless VPN product. It used java application components ( that only 
worked right with certain JRE versions ) and installed a kernel mode 
winsock redirector to capture traffic. I was horrified to discover that 
some of what they did was accomplished by setting entries in the hosts 
file as ( yes ... really ) to force connections local. Believe 
it or not, this was a rather expensive Juniper product with hefty client 
license fees.

While SSL VPNs are becoming more and more popular, there is really no 
standard for them to adhere. Sure, they use SSL but for what and how 
effectively? You place the trust in the vendor to do the right thing and 
hope for the best. This also means that there is almost no chance for 
interoperability between SSL VPN product lines. Better for the vendor, 
bad for the consumer. Tunneling traffic over TCP also has some severe 
performance drawbacks. There is a reason why IP security protocols ( not 
socket layer protocols ) are written in a connectionless fashion. They 
have no business providing services like guaranteed messaging.

OpenVPN uses SSL for negotiation and key exchange. When securing user 
traffic, it actually uses the IPsec ESP protocol ( w/NAT-T extensions ). 
So calling it an SSL VPN solution is really a misnomer. Its really a 
Hybrid solution and a very good product all around.

Luckily, there is also a standard for securing IP communications. Its 
has widespread adoption, a huge installation base and inter-operates 
well between vendor implementations. Its called IPsec.

CD: 3ms