There’s been a recent shift in VPN architectures over the last few years –we’re seeing new solutions being built that use SSL encryption rather than the traditional IPSEC for a VPN protocol.
The “traditional” VPN architecture involves a VPN concentrator (often located on the firewall, but in some cases it’s a dedictated box), which uses IPSEC protocols to authenticate, authorize and then encrypt all traffic between the end user and the corporate systems.  What this normally means in practice is ISA (udp/500 and/or udp/4500) is used for authentication and authorization, and ESP (ip protocol 50) is used to encrypt the traffic.  In most cases, NAT Transparency (NAT-T for short) is implemented, so that ESP is encapsulated within upd/500 to better deal with home firewalls (or hotel firewalls, coffee shop firewalls etc).  IPSEC VPN tunnels generally need VPN client software installed, and often a file-based VPN profile to connect up.

SSL seems to be where everyone wants to go.  The initial session establishment, authentication and authorization is done via the browser, and the VPN session itself is then done by downloading a VPN client in the browser (often java based), and running that.  This has a few major attractions – all the firewall issues go away, almost every firewall known is configured to pass SSL (tcp/443).  SSL is also well known and is “known to be secure” of protocol – in fact it is often configured to use more or less the same encryption protocols as the IPSEC VPN solutions (AES256 these days). 

Finally, most SSL VPN solutions don’t require a client to be installed in advance.  Any home PC, kiosk or whatever can connect up to the VPN, do some business, then disconnect.
I bet you can see where I’m going on this, and it’s all about policy.  Many corporations have “you can only connect with our hardware” policy.  Using home PC’s, kiosks or whatever allows whatever malware is on those units to access your inside network (or whatever your VPN authorization allows them to access that is.)

Perisistence is strike 2 against SSL VPNs.  Most SSL VPNs have a “zero footprint” option, that is supposed to delete all traces of the client after the session.  But periodically, every vendor has trouble with this.  We see problems where cached credentials or cached hashes allowing access are not properly deleted on exit, they’re left waiting on disk for a determined researcher (or their malware) to find.

A third strike is the fact that SSL, and SSL weaknesses, are well understood.  There are loads of SSL Man in the Middle tools out there.  Coupled with improper implementation, this can be a big problem.  Don’t forget that certificates server two functions – encryption and trust.  If you use a self-signed certificate, you’ve just defeated the “trust” side of things.  If users see a “I don’t trust this certificate” error every time they connect because the VPN Gateway was configured with a self-signed cert, they’ll see that exact same error if they’ve been compromised by a MITM attack.  Not only that, but you’ve trained your user base to press OK on certificate errors, so now they’re all at risk every time they see such an error on a banking or online retail site.

Is it “three strikes and you’re out” for SSL VPNs?  Don’t believe that for a second.  Every vendor is pushing us in this direction, all the new client improvements seem to be coming for the SSL versions only – IPSEC seems doomed to be the “legacy protocol” for remote access VPNs.

Do you use IPSEC or SSL VPNs in your environment?  Are you transitioning to SSL, or are you staying with IPSEC for the short term (or long term)?  Please, share you experience using our comment form.
 

=============== Rob VandenBrink Metafore ===============