Why VPN can't replace Wi-Fi security

Summary:This entry is also available as a PDF download.Every time the subject of wireless LAN security comes up, people ask me about VPN as a solution for securing Wi-Fi.

This entry is also available as a PDF download.

Every time the subject of wireless LAN security comes up, people ask me about VPN as a solution for securing Wi-Fi. (Wi-Fi is the common marketing name for 802.11 wireless LANs).  I've always told people that VPN security shouldn't be a substitute for good Wi-Fi security, and I even posted a comprehensive guide to enterprise wireless LAN security, but a loyal group of VPN-only supporters has always argued for a VPN-only alternative.  I'm going to explain VPN and Wi-Fi security as best I can and why there is a right time and right place for each architecture.

The VPN-only camp

The VPN-only camp consists of companies that have a vested interest in selling VPN solutions and some individuals who are more familiar with VPN than Wi-Fi security so therefore everything looks like a VPN-type problem because that's within their comfort range.  It's a classic case of when all you have is a hammer, everything looks like a nail.  They'll tell you to not worry about Wi-Fi security and just use VPN. The typical argument from the VPN-only camp is that the IEEE 802.11 standards body can't be trusted to come up with a good solution for Wi-Fi security.  To bolster their claims that Wi-Fi can't be trusted, the VPN-only camp will cite the example of the WEP debacle and/or they'll even point out how "WPA is cracked."

Was WPA really cracked? Anyone who states that "WPA was cracked" doesn't really understand what WPA is or what cracked means.  What they're actually referring to is the fact that a certain simple mode of WPA (designed primarily for home use), which uses PSK (pre-shared keys), can be cracked when a simple, easy-to-guess PSK is in use.  But that's only an example of a poor deployment of WPA-PSK. A simple 10-character alpha-numeric random PSK (or greater) will make it impractical to crack with dictionary attacks.  I can just as easily point out that the same mistakes can be made in certain VPN deployments that also make use of pre-shared keys.

Is WEP a permanent indictment of IEEE 802.11? There is no question that WEP is completely broken beyond redemption.  802.11 WEP encryption was designed during the late 90s during a time of strict U.S. export restrictions, when good cryptography was considered advanced munitions. I've had sources familiar with that process tell me that stronger encryption algorithms were shunned for fear of Wi-Fi products being banned for export.  Not surprisingly, it took less than two years for the cryptographic researchers (Fluhrer-Mantin-Shamir) to demonstrate serious flaws with WEP.  But something designed in the late 90s for exportability should not be a permanent indictment of Wi-Fi security or the competence of the IEEE 802.11 standards body.  If that's the standard we're going to judge by, we can pretty much shun everything on the Internet.  Moving beyond the WEP debacle, the Wi-Fi industry couldn't wait for the IEEE to fix the standard, so they adopted TKIP (a patched version of WEP) with the WPA industry standard.

Bad implementations should be shunned, not entire categories There are other bad implementations of VPN and Wi-Fi that have poorly designed authentication mechanisms.  ASLEAP, for example, is a tool that will easily crack both LEAP Wi-Fi 802.1x authentication and PPTP VPN authentication in nearly identical fashion, yet both protocols are (unfortunately) very popular.  The argument should be made against poor cryptographic implementations, not against Wi-Fi security in general.

<Next page - Wi-Fi and VPN security defined>

Wi-Fi and VPN security defined

Modern Wi-Fi security
WPA or WPA2 security came from an industry association called the Wi-Fi Alliance, and both incorporate solid cryptographic principles and algorithms.  WPA was based on the original draft of the 802.11i standard, and WPA2 was based on the finalized version of 802.11i.  Wi-Fi encryption happens on the "data link layer" (Layer 2 of the OSI model) and happens transparently in hardware and firmware.  Note that there are exceptions to the Layer 2 rule with the advent of switched Wi-Fi topology, where access points all tunnel to a centrally managed switch.

For encryption, the only difference between WPA and WPA2 is that WPA2 mandates both TKIP (a proper implementation of RC4) and AES encryption (good enough for top secret government security), whereas WPA mandated only TKIP encryption with optional AES support.  Neither TKIP or AES is considered broken, though AES is unquestionably superior.

WPA/WPA2 has two modes of authentication and access control: home PSK mode and enterprise 802.1x mode.  For home mode, the use of multiple rounds of hashing makes dictionary attacks painfully slow and the implementation of a "salt" in the key rules out the use of pre-computed hash tables (unless attacking a common SSID).  The enterprise mode of WPA calls for 802.1x, which is a standard for port-based network access control that is open to a wide range of EAP (Extensible Authentication Protocol) types.  The stronger EAP types, like EAP-TLS, PEAP, or EAP-TTLS, use PKI digital certificates for strong authentication.  Weaker EAP types, such as Cisco LEAP, transmit hashed passwords in the clear and are easy to crack with dictionary attacks.  Other weak implementations, like Cisco EAP-FAST, are typically deployed with anonymous digital certificates, which make them almost as easy to attack as LEAP.

Modern VPN security VPN (virtual private network) is a privacy technology where the encryption usually happens at the network layer (Layer 3 of the OSI model) with technology such as IPSEC, PPTP, and L2TP.  More recent VPN implementations have moved to SSL tunneling for ease of firewall, NAT, and proxy traversal (bypass) where the encryption happens at the presentation layer (Layer 6 of the OSI model).  Note that most VPN solutions emulate a Layer 2 connection by encapsulating Layer 2 within Layer 3 IPSEC or Layer 6 SSL.  Layer 2 emulation allows the VPN client to have a virtual IP address on the remote LAN it's connecting to.  Some SSL-tunneling VPN (not to be confused with application layer SSL-VPN) vendors, like Cisco, use ActiveX and/or Java installers to make it possible to rapidly deploy the VPN client from a Web-based install.  Microsoft will soon begin to incorporate a new SSL-tunneling technology, called SSTP, into Windows' built-in VPN client, which currently supports only PPTP and L2TP.

Encryption and authentication used in VPN vary depending on the implementation.  Implementations such as PPTP VPN use RC4 (40-, 56-, and 128-bit), whereas IPSEC and L2TP can use a wide range of encryption algorithms, like DES (56-bit), 3DES (168-bit), and AES (128-, 192-, and 256-bit).  Authentication mechanisms in VPN can be weak, like PPTP, which transmits hashed passwords in the clear, or they can be strong PKI-based implementations, like L2TP, which uses server and client digital certificates.  Some IPSEC solutions will have the option of using a pre-shared key or PKI-based digital certificates.  If this sounds a lot like Wi-Fi security above, it's not your imagination -- the principles of cryptography are universal.

<Next page - Where VPN and Wi-Fi security fits in>

Where VPN and Wi-Fi security fit in

VPN and Wi-Fi security each has its role in network security.  VPNs allow you to connect securely over any network (including the Internet) whether you're using a dial-up modem or a Wi-Fi hotspot connection.  This allows VPN to work from virtually anywhere in the world that provides Internet access.  Wi-Fi security, on the other hand, offers you security only at the data link layer between your mobile device and the wireless access point, which usually means it can only work locally in a LAN environment.  But Wi-Fi security solutions provide significantly more speed, less overhead, and less complexity.  The purpose of Wi-Fi security is to give you equal or better security than using a wired connection to the LAN with an equal level of functionality.

When you're using a VPN connection, the connection to the LAN over the Internet doesn't happen until the user logs in and fires up the VPN client software and manually starts a connection.  With Wi-Fi security, it is possible to use machine authentication to securely connect the computer before the user even logs into the PC.  That means maintenance tasks like Windows Update, enterprise management tools, group policy updates prior to or during login, and new user login can all be supported.  When a user wakes and logs into a laptop, it automatically and instantly logs the user into the wireless LAN with no user interaction.  Centralized management and distribution of Wi-Fi client configuration make Wi-Fi security very appealing to the enterprise.  There are also cases where VPN simply can't do the job at all because many embedded devices, like Wi-Fi VoIP phones, Wi-Fi label printers, and Wi-Fi barcode scanners, can't support VPN but they will support Wi-Fi WPA/WPA2 security.

Wi-Fi security coexisting with VPN security

In the network topology diagram above, we have a hybrid solution where both VPN and Wi-Fi security are deployed in an enterprise network.  The VPN gateway provides encrypted connections to users coming from the Internet, while the access points (more than one represented) provide wireless LAN connectivity for local devices.  The Wi-Fi network here is a closed network, where access control and authentication are performed BEFORE a Wi-Fi association is granted and the encryption is performed in hardware for everything at Layer 2 and above.  This topology utilizes a centralized RADIUS authentication model that is shared by all the access points and VPN gateways.  The access points and VPN gateway are the network access devices that forward RADIUS authentication requests to the RADIUS server, which in turn checks with the user directory (LDAP, Active Directory, Novell, etc.) for verification.  This offers true single sign-on for both Wi-Fi and VPN security with no waste in hardware.

VPN-only network-layer security

In the network topology above, VPN is the only solution being used to cover both VPN and Wi-Fi users.  It works to a limited extent such that laptops, Windows Mobile, Windows CE, and portable Linux devices can connect to the internal LAN as if they were connected with a VPN via an Internet hotspot.  But embedded devices, like Wi-Fi VoIP phones, Wi-Fi label printers, and barcode scanners, aren't so fortunate; they aren't supported by this architecture.  The performance is bottlenecked at the VPN gateway, which may require an upgrade to a gigabit-capable gateway.  Local Wi-Fi users are forced to go through a two-phase connection, where they first connect to the Wi-Fi network and then fire up their VPN software.

The AES encryption hardware in the access points and wireless network cards sit idle while the software VPN client eats up memory, MTU packet overhead, and clock cycles on the CPU.  Seamless fast roaming from access point to access point becomes more difficult.  Hackers can jump onto the wireless access points and play dirty tricks, like starving the DHCP server by filling it up with bogus requests, or possibly perform other Layer 2 attacks.  Hackers can probe for weaknesses in the other legitimate Wi-Fi clients because everyone is on the same subnet, and you had better hope everyone has a host-based firewall that's locked down tight.

Forcing a VPN-only topology means:

  • More expensive gigabit-capable VPN gateway
  • Saving nothing on Wi-Fi related infrastructure
  • Getting less performance and more overhead
  • Getting less compatibility to embedded devices
  • Offering less manageability with no pre-login connectivity
  • Allowing the hacker to get onto your open Wi-Fi network and probe your network and Wi-Fi clients for weaknesses

It's clear that the best approach is to use the right tool for the right job.  VPN security is like a hammer and Wi-Fi security is like the screwdriver.  You can't use a screwdriver to drive in a nail, and you wouldn't use a hammer to drive in a screw.  You can force a screw in with a hammer, but it won't always give you the desired results.

<Home - Start of article>

Topics: Networking, Wi-Fi

About

George Ou, a former ZDNet blogger, is an IT consultant specializing in Servers, Microsoft, Cisco, Switches, Routers, Firewalls, IDS, VPN, Wireless LAN, Security, and IT infrastructure and architecture.

Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.