Republished with permission from
WatchGuard Technologies, Inc.
Mix-n-Match VPNs: IPsec and SSL
[Editor's Note: Ever since WatchGuard introduced an SSL VPN solution, we've been asked, "Which is better, IPsec VPN or SSL VPN?" Both solutions have strengths and weaknesses, which Lisa Phifer aptly explains here. If you like her writing, be sure to read her excellent article on controlling the use of mobile devices in your network, featured in this month's Information Security magazine. --Scott]
Virtual Private Networks use public links to carry private data. Although many protocols can secure VPN traffic, IPsec is the most common, deployed by 57% of businesses today. But last year, Forrester found that 2 in 5 enterprises had experimented with SSL VPNs. By 2008, Gartner predicts that SSL will be the primary VPN used by teleworkers (66%), contractors (75%), and employees needing occasional remote access (90%).
This shift has prompted many companies to ponder: Should we use SSL instead of IPsec? But here's what you should really ask: Would combining IPsec and SSL better meet your business needs? IPsec excels at certain tasks; SSL at others. To ensure a good fit, you must match your VPN requirements to what each has to offer.
No matter what their business purpose, all VPNs fit into one of three topologies:
The latter does not involve network tunneling , so let's focus on branch office and mobile user VPNs. What functions do tunneling protocols like IPsec and SSL perform in BO and MU VPNs?
Given this as our foundation, let's explore how IPsec and SSL VPNs work.
Symmetric authentication between IPsec tunnel endpoints (Gateway-Gateway or Gateway-User) is provided by the IKE. Both ends (IKE peers) must use the same kind of credential: Pre-Shared Secrets, Public Keys, or Digital Certificates.
IKE peers control traffic flow using IPsec selectors -- filters based on IP protocol type, source/destination subnet or host address, and source/destination port numbers. A BO VPN selector might say "tunnel TCP and UDP between 192.168.0.0/24 and 192.168.1.0/24." An MUVPN selector might say "tunnel IP to/from ANY subnet."
When a selector requires tunneling, the sender (Gateway or User) wraps the private (inner) IP packet inside a public (outer) IP header and applies one of two IPsec protocols: ESP or AH. AH uses a Hashed Message Authentication Code (HMAC) like MD5 or SHA1 to ensure Integrity of the entire (outer+inner) packet. ESP provides Integrity and Confidentiality for the inner packet only, using a block cipher like 3DES or AES.
At the far end of the tunnel, the receiver checks the HMAC, discards modified/replayed packets, and (for ESP) decrypts the inner packet. The outer header is stripped, and the inner packet is forwarded to its destination inside the private network.
This architecture makes it is easy to see why IPsec is a great choice for branch office VPNs:
When it comes to mobile user VPNs, we can see that IPsec is limited:
SSL and its IETF descendent, TLS, are widely supported by Web browsers. They provide asymmetric authentication: the Server is authenticated by certificate; the Client is authenticated with any method (e.g., passwords, tokens, certificates) requested by the Server.
SSL Clients and Servers tunnel application messages (e.g., HTTP) over TCP sessions. The sender compresses the application message and breaks it into fragments. It applies a Hashed Message Authentication Code (HMAC) like MD5 or SHA1 to ensure fragment integrity. The MAC and fragment are encrypted with a block cipher (like AES) or a stream cipher (like RC4) and wrapped inside an SSL Record header.
At the receiving end of the tunnel, the receiver strips the Record header, decrypts the Record payload, and checks the HMAC to discard modified or replayed fragments. Fragments are reassembled and decompressed to reconstitute the original application message.
Traditional Web browsers and servers just use SSL to secure HTTP transactions. SSL VPNs like the WatchGuard Firebox SSL Core go farther, using this widely-deployed protocol to tunnel a variety of applications between mobile users and VPN Gateways.
SSL VPN Gateways let designated users or groups access specific application protocols, commands, and objects (e.g., URLs, folders). For example, an SSL VPN might let a traveler with a laptop access several enterprise applications, while limiting a teleworker to email and his own mailbox folders.
All SSL VPN products leverage the user's existing Web browser and SSL/TLS to contact the VPN Gateway, authenticate both tunnel endpoints, and enforce authorization policy. But, unlike IPsec VPNs, SSL VPN product architectures vary widely, and this directly impacts their mobile user VPN features and capabilities.
Some SSL VPNs require all application protocols to be "webified" -- converted to HTTP. These Gateways proxy HTTP to enterprise applications, rewriting URLs to hide private network and data topology. They often support applications with native Web user interfaces (e.g., Microsoft OWA, IBM IWA), but require customization for non-Web applications, and Web applications that pass binary content (e.g., Java, Active X, Flash.)
Other SSL VPNs relay native application protocols over the SSL tunnel by running a "port forwarding" agent on the mobile user's device. This agent (e.g., Java applet, Active X control, Win32 executable) is supplied by the VPN Gateway to authenticated users. Depending on the product, applications may still be limited -- for example, forwarding only TCP sessions initiated by the mobile user.
The WatchGuard Firebox SSL Core takes a unique approach to overcome common SSL VPN limitations. Authenticated users are presented with a Gateway portal page where they choose between connecting from "My own computer" and "A public computer."
Overall, we can see that SSL VPNs are well-suited for mobile user VPNs, but inappropriate for branch office VPNs. If your mobile workforce consists of trusted users and devices that require network-level access to everything inside your private network, IPsec may meet your MUVPN needs. But, if you must deal with a mixture of trust levels and/or device ownership, or simply want to avoid IPsec Client installation, an SSL VPN can probably better help you meet those needs.
However, SSL VPNs operate in such diverse ways that choosing the right VPN to meet mobile user needs requires looking not just at the protocol, but at individual products. To learn more about WatchGuard's SSL VPN solution, please refer to these resources:
Copyrightę 2006, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.