Problem solve Get help with specific problems with your technologies, process and projects.

IPSec VPN vs. SSL VPN: Comparing respective VPN security risks

When it comes to VPNs, which of the two most-used options -- IPSec or SSL -- presents the greater security threat? Expert Anand Sastry describes the pros and cons of each, as well as how to test your VPN implementations for security.

Virtual Private Networks (VPNs) have now become the de facto standard to provide a company’s partners or employees...

with remote access to corporate resources in a secure manner. In this tip, we attempt to explain the difference between two popular VPN types -- IPSec VPN vs. SSL VPN -- and how to decide between them.

Before I delve into these two different types, however, a quick overview of VPN technologies is in order. VPN refers to the family of technologies that facilitate remote access to corporate resources. The primary users of this technology are company employees who want to access resources at work from their homes or other public places, and corporate partners/third parties who support various systems within the corporate infrastructure. VPNs typically leverage public long-haul IP networks to transmit data by creating an encrypted channel between the remote site, which could be an employee’s laptop or a third-party system, and the corporate network.

Key technologies
At present, the two most popular VPN technologies are the traditional Internet Protocol Security (IPsec)-based VPNs, which function primarily at the network layer, and Secure Sockets Layer (SSL) VPNs, which function primarily at the application layer. These differ in both the underlying technology used, the function they serve, as well as in the potential VPN security risks they present.

IPsec was originally designed to provide point-to-point, always-on connections between remote sites and the central office resource. The clients in this case could be branch offices or vendors. The protocol is designed to work further down the network stack (layer 3) and can be used to transmit any IP-based protocol, irrespective of the application generating the traffic. With the advent of the mobile work force, IPsec has been extended to support remote access through the use of a dedicated VPN application (client) installed on the users' mobile assets.

SSL VPNs, on the other hand, were designed with the mobile workforce in mind. The intended goal was to provide a seamless, clientless method for remote access. An SSL VPN can be thought of as an application proxy, providing granular access to specific corporate resources that a remote user can access using his or her browser without the need to install a client.

Strengths and weaknesses
IPsec ‘s key strength lies in its ability to provide a permanent connection between locations. Working at the network layer (layer 3 of the network stack) also makes it application agnostic: Any IP-based protocol could be tunneled through it. This makes IPsec an attractive alternative to an expensive leased line or a dedicated circuit. It could also serve as a backup link in the event that the primary leased line or dedicated circuit connecting the remote site to the central office goes down.

IPsec's application-agnostic design is also its weakness, however. Though it provides authentication, authorization and encryption, while basically extending the corporate network to any remote user, it does not have the ability to restrict access to resources at a granular level. Once a tunnel is set up, remote users can typically access any corporate resource as if they were plugged directly into the corporate network. These VPN security concerns are exacerbated because having a mobile workforce requires allowing non-managed IT assets like smartphones and home PCs to access corporate resources. These are assets that IT has no visibility into or control over, and there is no guarantee that these devices comply with the level of security that is typically enforced on managed assets.

IPsec is also more involved to maintain. In addition to setting up the appliance to terminate the tunnels, additional configuration and maintenance are required to support the remote user population. In situations where corporations use Network Address Translation (NAT), special configuration is required to ensure IPsec plays nicely with the NAT setup.

SSL VPNs, on the other hand, have been designed from the ground up to support remote access. They do not require any special software to be installed. Remote access is provided through a browser-based session using SSL. SSL VPNs also provide an enterprise with the ability to control access at a granular level. Specific authentication and authorization schemes for access to an application can be limited to a particular user population. Built-in logging and auditing capabilities address various compliance requirements.  SSL VPNs also have the ability to run host compliance checks on the remote assets connecting to the enterprise to validate they are configured with the appropriate security software and have the latest patches installed.

This does not mean SSL VPNs are the panacea to all of IPsec’s weaknesses. If a remote site requires an always-on link to the main office, SSL VPN would not be the solution. IPsec, being application agnostic, can support a number of legacy protocols and traditional client/server applications with minimal effort. This is not the case with SSL VPNs, which have been built around Web-based applications. Many SSL VPNs get around this weakness by installing a Java or ActiveX-based agent on the remote asset. This installation is typically achieved seamlessly after the remote asset has successfully authenticated to the SSL VPN appliance, though it should be noted that both ActiveX and Java come with their own security weaknesses that attackers commonly seek to exploit.

IPsec or SSL VPNs?
Each VPN method has its place in an enterprise. Ideally, as SSL and IPsec VPNs serve different purposes and complement each other, they should both be implemented. IPsec should be leveraged in situations where an always-on connection to remote office locations or partners/vendors is required. In these instances, granular access control limitations and missing host-check capabilities should be augmented with a Network Access Control (NAC) system, which can ensure only approved remote hosts are allowed to connect to the enterprise. Enterprises should leverage SSL VPNs primarily as a remote access method for the mobile workforce where granular access control capabilities, auditing and logging, and security policy enforcement are crucial. But, regardless of your VPN choice or specific needs, remember that a VPN must not only be updated, tested and monitored for performance, but also employed as part of a defense-in-depth strategy that utilizes comprehensive policies and a variety of network security technologies.

About the author:
Anand Sastry is a Senior Security Architect at Savvis Inc. Before joining Savvis, he worked for clients in several industries (large and mid-sized enterprises in financial, healthcare, retail and media) as a member of the security services group for a Big 4 consulting firm. He has experience in network and application penetration testing, security architecture design, wireless security, incident response and security engineering. He is currently involved with network and web application firewalls, network intrusion detection systems, malware analysis and distributed denial of service systems. He tweets at

This was last published in May 2011

Dig Deeper on VPN security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.