Cyber Security Awareness Month - Day 19 - VPN Architectures ? SSL or IPSec?

Published: 2010-10-19
Last Updated: 2010-10-19 13:50:27 UTC
by Rob VandenBrink (Version: 1)
7 comment(s)

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

7 comment(s)

Comments

What's wrong with IPSEC? We've been using it for years with none of these "firewall" problems. Also, I've yet to find an SSL VPN that doesn't require the installation of a VPN client. I've had more trouble with SSL VPN clients that are less portable than IPSEC VPN clients (with the exception of OpenVPN). I don't get the IPSEC hate.
I think the hate is from the vendors because they can lock you in with licensing for the SSL where they were giving away the IPSEC in the past. If its open you can go somewhere else if its closed your semi locked in.
> 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.

... as opposed to teaching them that Verisign certs et al are trustworthy? No seriously, you can trust me. I have a cert that says I'm Microsoft. I have Two, in fact! They're not even MD5, so you know they're real!

Totally agree on the SSL vendor thing... yet another Buzzword-du-jour, sadly.
Not a security issues, but SSL, being TCP-based, has some performance issues when used as a tunnel, as described by Honda et al (http://spie.org/x648.html?product_id=630496), which describes some undesirable effects coming from having two TCP congestion control algorithms running on top of each other (one at the tunnel layer, then one within the tunnel).

But I regularly use SSL and SSH tunnels without noticing problems.
I use both types of remote access VPNs - note that w/ current standard for NAT-Traversal - ESP (IP protocol #50) is more typically encapsulated inside UDP port 4500 traffic. That port is used for ISA negotiations and for data transmission. Even wireshark can tell the two functions apart in captures. using UDP 500 for this purpose was more common a few internet-dog-years ago.
We recently implemented OpenVPN which from what I know uses SSL/TLS. I'd like to know everyone's opinion on that? They way we use it is with client/server certificates, no web browswer access.
IPSec was hard to setup before Windows 7 (if ever it could work). Now it is easier but still doesn't support current encryption/HMAC protocols. Moreover it is hard to setup on many appliances/systems (though it is not mandatory : take a look at OpenBSD solution, that's pure gold !)

That's no wonder why SSL sells ! (even if it saddens me)
- it can work with OTP-tokens
- it is easy to use
- my users have the company CA in their browser so they don't have to trust the cert every time ;)

Diary Archives