The virtual private network (VPN) is now a widely accepted feature of corporate IT security – and SSL is gaining on the established IPSec standard as the most popular VPN security protocol. How do they stack up?
The primary reason for VPN growth is that VPNs are a cheaper alternative to costly lease line solutions, given that an enterprise has to have a physically closed, secure network connection between its partners and remote employees. Virtual Private Networks or VPNs allow corporate enterprises to extend access to their internal networks to external employees and partners over public networks: VPN technology means that employees and partners can use standard public Internet ISPs and high-speed lines to access closed private networks.
VPNs use encryption and security protocols - transmission protocols that are used to transmit high value data securely. A common misconception is that VPNs always use the IPSec protocol – but there are other encryption and security protocols that support the functionality of a VPN. SSL is one such protocol – and is probably now the best known after IPSec, the incumbent technology. According to analyst Gartner: "SSL-based portals will increasingly be the choice for enterprises that want highly portable, nearly clientless solutions. By year-end 2004, 60 per cent of corporate users will regularly use an SSL, instead of a full, fat-client VPN, for access to business data".
But is SSL a viable alternative to IPSec? As a 'new' protocol, can it offer the same security strengths that have made IPSec the de facto standard to date?
IPSec under the microscope
IPSec – or Internet Protocol Security – is an encryption protocol that provides for secure encrypted data transmission at the network layer across a public network. It is long established, tried and tested.
Two parties who wish to create an IPSec communication 'tunnel' must first negotiate on a standard way to communicate. Since IPSec supports several modes of operation both sides must first decide on the security policy and mode to use, which encryption algorithms they wish to communicate with and what type of authentication method to use.
In IPSec, all protocols, which sit upon the network layer, are encrypted (once an IPSec tunnel is created) between the two communicating parties, in line with traditional IT security practice. TCP, UDP, SNMP, HTTP, POP, AIM, KaZaa etc, are all encrypted regardless of their own built in security and encryption.
Because IPSec sits at the network layer not only is all the network traffic encrypted: the user also gains access to all company resources as if they were physically resident in the office connected to that LAN. This apparent strength can in some circumstances also be a weakness: after all, a company may or may not want partners or temporary remote employees to be part of its network.
IPSec requires special-purpose client software that in most cases replaces or augments the client systems TCP/IP stack. However this may cause compatibility issues with other system software as well as the security risk of Trojan Horses being loaded – especially if the client software is downloaded through the Web and not installed by an IT person.
IPSec clients are bound to a specific laptop or desktop system – a feature that some feel is in line with a rigorous security policy.
However this may limit the mobility of users, as they cannot connect to the VPN without an IPSec client first being loaded on the client system they use to access the network. No roaming access from airport lounges...
IPSec solutions often require high IT support for both implementation and long-term maintenance. Large corporations often have several helpdesk personnel devoted to supporting their employees who work remotely via IPSec. Also, IPSec clients typically only run on Windows machines: Linux, for example, is not an option.
SSL under the microscope
SSL – or Secure Sockets Layer – is an application layer protocol used most often to secure web-based communications over the Internet. SSL uses encryption and authentication much like IPSec. However SSL only encrypts the traffic between two applications that wish to speak to each other – it does not encrypt all the traffic from one host to another.
Within SSL, each application is secured individually, unlike IPSec, which operates independently of the application. An application must be 'SSL aware' in order to be able to speak SSL. Common applications that are SSL aware include web browsers such as Internet Explorer and Netscape; email applications such as Outlook and Eudora.
There is a growing trend to use a SSL proxy instead of communicating directly from a client to a SSL enabled resource. The most common reason is performance. Most modern web servers can only accept about 75 new SSL connections per second, and for each new connection a decrypt and verify operation must be performed. If the system takes more than 75 connections per second, the CPU utilisation goes beyond what is acceptable and the server stops responding to network requests.
To increase the server's capacity, SSL proxies may include an SSL accelerator, which performs the computationally intense operations normally performed by the servers' CPU - and offloads those operations to a purpose built processor that allows the server to handle some 800 sessions/second.
Using an SSL proxy it is possible to utilise the SSL accelerator once for many servers – without the web server becoming overloaded with SSL connection requests.
The SSL protocol lacks built-in authentication methods and it may be necessary to add additional authentication methods on top of SSL to ensure the user or client is who they say they are. A SSL proxy, however, will strongly authenticate the clients before they connect to the back end resource.
Web browsers and SSL enabled email clients exist in many forms today including Windows, Macintosh, Linux/UNIX, PDAs and even mobile phones. All can communicate securely via SSL. Users are already familiar with these tools so the need for training is reduced.
One of the disadvantages of IPSec is that it only creates a secure tunnel between a client and an edge VPN Server. The only secure connection is the one between the client and the edge of the corporate network - all the data running over the internal network is unsecured, including passwords and sensitive data.
With SSL a secure tunnel is established directly from the client to the resource the client is accessing: end-to-end security. Everything from the client to the resource is securely authenticated and encrypted.
VPN and the mobile enterprise
IPSec is a rigorous security protocol that has proved its effectiveness for in point-to-point connections (where the IT organisation has control of both points), in the corporate VPN environment. For many organisations it will continue to do so – but for others, especially those whose environment is changing, it may not.
However, collaborative commerce and the mobile enterprise demand a new flexibility that may find IPSec cannot provide. wanting. Approximately 90% of all corporate intranet and extranet traffic is now standard web- and email-based, . For those networks that have primarily web and email traffic, and more and more user access points are outside the control of the firm's IT organisation (home, partners, road warriors etc). In this environment SSL is the clear choice, offering that need to support a mobile enterprise, a VPN solution based on IPSec may not be the best choice. In those cases, SSL offers a more mobile, scaleable and administratively simple solution.
In conclusion, this is probably not an "IPSec or SSL" decision:most organisations will continue to need both solutions, with IPSec providing point-to-point VPN while SSL provides for the rest.
David M. Lynch is vice president of marketing at Array Networks, a secure global access company.
