SSL VPN vs. IPSec VPN
White Paper
254 E. Hacienda Avenue Campbell, CA 95008 www.arraynetworks.net (408) 378-6800
SSL VPN vs. IPSec VPN
White Paper
Introduction
Virtual Private Networks or VPNs allow corporate enterprises to extend access to their internal networks to external employees and partners over standard Internet public networks. The primary reason VPNs came to be was the immense expense lease line solutions incurred. An enterprise had to have a
physically closed network connection between its partners and remote employees, either through dial-up RAS (Remote Access Server) solutions into the enterprise network, or lease fractional T1 type
connections between remote offices and partners.
What is a VPN really?
VPNs are the enabling technology, which allows for clients (employees) and partners to use standard public Internet ISPs and high-speed lines to access closed private networks. A common misconception is that VPNs are always IPSec protocol solutions. In fact, there are many encryption and security protocols, which offer the functionality of a VPN. SSL is one such protocol.
What is an encryption or security protocol?
Encryption and security protocols are transmission protocols, which are used to transmit high value data securely. Encryption, which is at the core of any security protocol, gives you three fundamental
advantages over ‘clear-text’ or unencrypted data:
• Data privacy - or the ability to hide the data which is being transmitted
• Data authenticity and integrity - because of the math involved in encryption, security protocols have the ability to ensure data has not been modified or damaged in transit
• Non-repudiation - another feature of the math contained in encryption is the ability to prove an act occurred
What is IPSec?
IPSec – or Internet Protocol Security, the security protocol most commonly associated with a VPN – is an encryption protocol, which provides for secure encrypted data transmission at the Network Layer across a public network such as the Internet. Two parties who wish to create an IPSec 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 authenticate 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. TCP, UDP, SNMP, HTTP, POP, AIM, KaZaa etc, are all
encrypted regardless of their built in (or lack of built in) security and encryption.
IPSec issues and complaints
Because IPSec sits at the network layer not only is all your network traffic encrypted, but also the user gains access to all company resources as if they were physically resident in the office connected to that LAN. You may or may not want partners or temporary remote employees to be part of your network. Your network may only need to have a small portion of its traffic secure. You may not want to encrypt
everything from the remote client to the corporate network.
Issue 1: Client software
IPSec requires special-purpose client software, which in most cases replaces or augments the client systems TCP/IP stack. In many systems this introduces the risk of 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. Due to the way IPSec was created and the lack of conformance to the standard, nearly all IPSec implementations are proprietary and not compatible with each other.
In some cases IPSec runs on a network hardware appliance. With these types of solutions most often both communicating sides have to have the same hardware. The same compatibility issues with the client software apply to the IPSec enabled hardware.
IPSec clients are bound to a specific laptop or desktop system. This limits the mobility of the 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 here…
Issue 2: IT support
IPSec solutions require immense amounts of 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.
Issue 3: Platform limitations
IPSec clients typically only run on Windows machines. There are very few implementations of IPSec for any other PC platform (Mac, Linux, Solaris etc.)
What is SSL (SSL proxy) and how is it different?
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. SSL does not encrypt all the traffic from one host to another. For most client applications, encrypting all the traffic from one system to another is not required, and a solution that just encrypts the application data is more appropriate.
Within SSL, each application is secured individually, unlike IPSec, which operates independent of the application. An application must be “SSL aware” to be able to speak SSL. Common applications, which are “SSL aware” today, are Web browsers such as Internet Explorer and Netscape, email applications such as Outlook and Eudora include a feature called ESMTP or SMTP over SSL.
Why use an SSL proxy?
There are many reasons to use a SSL proxy instead of communicating directly from a client to a SSL enabled resource. The most evident reason is performance.
Reason 1: Increased performance
SSL itself is a very fast protocol, however like any encryption protocol there are special CPU intense math computations that need to take place before a secure session is established. One such example is the RSA algorithm. The RSA algorithm is used within SSL to negotiate keys between a client and a server.
As part of this key negotiation, the server must decrypt and verify a digital signature - both are
computationally intense operations. Most modern Web servers, for example, can only accept about 75 new SSL connections per second, and for each new connection this RSA decrypt and verify operation must be performed. If the system were to take any more than 75 connections per second, the CPU utilization would reach far beyond what is acceptable and the server would stop responding to network requests.
To increase the server’s capacity, SSL proxies may include what is called a SSL accelerator. A SSL accelerator is much like a math co-processor in the 486SX/DX PC days. The SSL accelerator performs the computationally intense operations formally performed by the servers’ CPU and offloads those operations to a purpose built processor. The server, which was only able to perform 75 RSA sessions/second, can now handle well over 800 sessions/second.
You may wonder why would you need an SSL proxy if your server has an SSL accelerator. The questions to ask are: “How many servers do you have which may need this SSL acceleration? Do you have the resources to purchase SSL accelerators for each of those servers?” The advantage of an SSL proxy is that you can utilize the SSL accelerator once for many servers.
In the Array SP (Security Proxy) from Array Networks, for example, you may open 800 SSL connections per second to the clients accessing your resource, while maintaining an SSL connection from the proxy to the back end server as well. Note the Array SP is able to open a reduced number of SSL connections to the back end while serving up to 800 sessions/second on the front of the Array SP. The advantage of this is your Web server is never overloaded with SSL connection requests.
Reason 2: Authentication
Another issue with the traditional SSL protocol is its lack of built-in authentication methods. SSL includes cryptographic authentication for both the server and the client. However, all of that security is based on one premise: The client’s cryptographic “private-key” was kept secure. If the key has been compromised or left unattended, you may no longer be able to trust the client. 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 ever connect to the back end resource. SSL proxies will enforce much stronger authentication methods than a back end resource could ever support natively. Many Web servers today do not natively support authentication methods other than SSL.
Why use an SSL proxy over an IPSec VPN?
No client-side software or hardware requirements
A key advantage to an SSL proxy is that no client software needs to be loaded and distributed through your client base. SSL proxies can use standard Web browsers and email clients, which are already enabled to use SSL.
Easy-to-use, easy-to-support Web interface
Web browsers and SSL enabled email clients exist in many form factors today including Windows, Macintosh, Linux/UNIX, PDAs and even cell phones all can communicate securely via SSL. People are already familiar with how to use these tools so end-user training is greatly reduced.
End-to-End vs. End-to-Edge Security
One of the major disadvantages of IPSec is that it only creates a secure tunnel between a client and an edge VPN Server. When the client requests access to a resource he is treated as if he was a member of
that same network as the resource resides. The only secure connection is the one between the client and the edge of the corporate network, however all the data running over the internal network is in the clear, including any passwords and sensitive data that are sent.
With SSL a secure tunnel is established directly from the client to the resource the client is accessing.
True end-to-end security. No data is sent in the clear neither on the internal network nor on the Internet.
Everything from the client to the resource is securely authenticated and encrypted.
90% of traffic is Web and Email based
Approximately 90% of all corporate Intranet and Extranet traffic is standard Web and email-based traffic.
The other 10% is comprised of other protocols such as X11, chat protocols and other proprietary “fat”
client applications that are not web-enabled. For those networks that have primarily Web and email traffic, a VPN solution based on IPSec may not be the best choice. The complexity and instability of IPSec client software, in addition to the mobility issues of your clients, put into question the usefulness of a VPN based on IPSec. SSL provides for a much more mobile and simple solution to administer.
Which technology is right for me?
IPSec – Should be used to secure those protocols which are not SSL enabled SSL – Should be used for all Web and SSL enabled email traffic.
SSL-based VPN IPSec-based VPN
Authentication • One way authentication tokens
• Two way authentication tokens
• Digital certificates
• Two way authentication using tokens
• Digital certificates Encryption • Strong Encryption
• Browser based • Strong Encryption
• Depends on implementation Overall Security • End to End security
• Client to Resource encrypted • Edge to client
• Client to VPN gateway only encrypted Accessibility • Anywhere anytime access to broadly
distributed user base • Access limited to well-defined and controlled user base
Cost • Low
• No additional client software needed • High
• Managed client software required Installation • Plug and play installation
• No additional client-side software or hardware installation
• Often long deployments
• Requires client-side software or hardware
Simplicity for user • Very user friendly - uses familiar Web browsers
• No end user training required
• Challenging for non-technical users
• Requires training Applications
Supported • Web-enabled applications
• File sharing
• All IP-based services
Users • Customers, Partners employees, remote
users, vendors etc. • More suited for internal company use Scalability • Easily deployed and scalable • Scalable on server side
• Difficult to scale clients
Summary
This white paper examines the major differences between IPSec based VPNs and SSL based VPNs. The advantages and disadvantages of each were explored. What you find is that for most intranet and
extranet traffic, a VPN based on IPSec might not be the best solution after all.
Considering the push to web-enable legacy corporate data, the need for a VPN based on IPSec is put into question. The requirement of a fat, unreliable client on every desktop just to access your corporate e- mail and intranet Web site, is perhaps not the best approach to corporate security or IT policy.
