Theres been a recent shift in VPN architectures over the last few years were 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 its 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 dont 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 Im going on this, and its all about policy. Many corporations have you can only connect with our hardware policy. Using home PCs, 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, theyre 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. Dont forget that certificates server two functions encryption and trust. If you use a self-signed certificate, youve just defeated the trust side of things. If users see a I dont trust this certificate error every time they connect because the VPN Gateway was configured with a self-signed cert, theyll see that exact same error if theyve been compromised by a MITM attack. Not only that, but youve trained your user base to press OK on certificate errors, so now theyre all at risk every time they see such an error on a banking or online retail site.
Is it three strikes and youre out for SSL VPNs? Dont 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 ===============
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.