Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


Mix-n-Match VPNs: IPsec and SSL

by Lisa Phifer, Vice President, Core Competence

[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.

VPN 101

No matter what their business purpose, all VPNs fit into one of three topologies:

  • In Branch Office (BO) VPNs, a Gateway (e.g., firewall) at one network edge relays private traffic over a tunnel to a Gateway at the destination network edge.
  • In Mobile User (MU) VPNs, an individual User (e.g., teleworker, traveler, hotspot visitor) relays private traffic to a VPN Gateway at the destination network edge.
  • Alternatively, private traffic can be secured end-to-end, all the way from the sending application (e.g., Client) to the destination application (e.g., Server).

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?

Authorization

Every VPN must enforce access controls that determine who is permitted to use private resources.

Authentication

VPN access rights are based on the traffic source's identity, which should be verified -- that is, proven authentic.

Confidentiality

Private traffic transmitted over public links should be encrypted to prevent "man in the middle" eavesdropping.

Integrity

The VPN must also be able to discard any traffic that has been injected, modified, dropped, or replayed in transit.

Given this as our foundation, let's explore how IPsec and SSL VPNs work.

IPsec VPNs

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:

  • Network gateways are an excellent place to consolidate policy configuration and enforcement. No host or user inside an office network need be VPN-aware.
  • Gateways can use hardware-assisted encryption to minimize VPN impact on applications that require high throughput or low latency.
  • It makes sense for Gateways to treat each other as peers -- their job is to merge office networks together, treating everyone as part of one big trusted network.

When it comes to mobile user VPNs, we can see that IPsec is limited:

  • IPsec Clients must be installed and configured on every mobile user's device. This is impractical for teleworker or business partner PCs, and impossible for public-use PCs and many non-Windows devices (e.g., smartphones, VoIP handsets).
  • Treating mobile users as peers can be inappropriate. For example, IKE cannot authenticate the Gateway by Certificate, but the user by Pre-Shared Secret.
  • Because IKE cannot interactively-authenticate users with passwords or tokens, Gateways like the WatchGuard Firebox implement eXtended Authentication (XAUTH). But this pragmatic extension can be vulnerable to attack [ 1][ 2].
  • IPsec selectors are superb when mobile users (and their hosts!) are trustworthy and full network access is required. But selectors cannot permit narrow, application-specific access by contractors, suppliers, etc.
  • When IPsec passes through Network/Port Address Translation, the outer IP header is modified. But changed AH packets are always discarded. To pass ESP, the NAT must implement special handling (VPN pass thru) because the inner packet's port is encrypted. Thus, IPsec works in some locations but not others, depending on if and how NAT is applied between the user and VPN Gateway.

SSL VPNs

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."

  • Those connecting from their own computer dynamically download the Citrix Secure Access Client on first access. This always-on client automatically tries to stay in contact with the Gateway, forwarding all applications (even real-time protocols) over the SSL tunnel. Like IPsec, this approach tunnels any IP packet, initiated in either direction. Unlike IPsec, this approach is unaffected by NAT and can support very granular access control policies.
  • Those connecting from a public computer use a "Kiosk Mode" Java applet that opens a Virtual Network Computing (VNC)-like window. That window provides mobile user access to shared drives and Citrix ICA, Remote Desktop, Secure Shell, Telnet 3270, or VNC servers. The VPN Gateway can enforce granular user or group-based policies, letting companies offer restricted access to public PC users without risking network-level exposure to those devices.

Conclusion

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.