ElcomSoft's application of GPU processing to wireless password cracking poses a problem for any users of WiFi corporate networks – so much so that Global Secure Systems has advised companies to either abandon wireless altogether, or to deploy VPNs for all wireless connections, even internally.
So it's a good time to take a look at the basics of VPNs, and the products that might help you deploy VPNs behind the firewall.
“VPN” is an expression that gets bandied about with little regard to consistency or comprehensibility. It might refer to a carrier WAN technology (such as IP/MPLS), or to a voice network (such as in “centrex” services), or to the encryption of a private tunnel over the Internet.
In this article, the VPN technologies I describe are of the latter kind – except that instead of deploying the VPN over the Internet, I'm talking about a deployment on the internal network.
In the Internet VPN, data is encrypted before it is transmitted over the network.
It is based on a VPN client and a VPN server, each of which have a key pair comprising a public key and a private key. When Bob, the client, has data to send to Alice, the server, the two first exchange their public keys, and Bob uses Alice's public key to encrypt the data prior to transmission.
When Alice receives the data, she uses her private key – not the public key used by Bob – to decrypt the message. For transmissions in the other direction, Alice similarly uses Bob's public key to encrypt the data, and Bob uses his own private key for decryption.
In such schemes, the data is protected even if a third party obtains one of the two public keys, since the public key isn't used to decrypt the data – for that, you need Alice or Bob's private key.
This can happen on a purely peer-to-peer basis. For example, two individuals may exchange each others' public keys so as to send encrypted e-mails (the OpenPGP button Mozilla Thunderbird users now see in their menus, but probably don't use).
But in a “bulk” application such as a business network, the business of manual key exchange becomes cumbersome, so the industry has developed a range of VPN solutions designed to do two things:
- Manage and automate the key exchange process; and
- Automate the ongoing encryption of all messages in a connection, for as long as that connection exists (referred to as a “VPN session”).
Commercial VPN solutions are designed to simplify the process. Users can only connect to the host network through the VPN server, so the network behind the server is (theoretically) not vulnerable to malicious traffic from outsiders; and at the client end, the process requires only that the user launch the VPN software and provide his/her credentials. The business of key exchange and encryption are invisible to the user.
Access control can be implemented with 802.1X. However, this was born as a port-based security system, and in its deployment to secure wireless systems, it can become subject to a range of man-in-the-middle attacks, allowing attackers to gain user credentials and present themselves as legitimate users of the network.
It's also important to remember that 802.1X's focus is access control rather than encryption. The protocol is designed to manage who is allowed to connect to the network rather than protecting the wireless traffic itself.
To secure the traffic as well, encryption is required – and the encryption built into wireless LANs is what's under attack by approaches such as Elcomsoft's cracker, which uses the power of graphics processors to ramp up an attacker's “brute force” capacity. Of course, if the users choose weak passwords, the brute force attack has a better chance of success in a reasonable time.
VPN Basics
Generally, modern encrypted VPN technologies today are based on either IPSec or SSL technologies.
The IPSec VPN is an implementation of a set of IETF standards covering key exchange, authentication and encryption.
While secure, IPsec requires client software to be installed on all the user machines to connect to the network. If the user's operating system doesn't include a built-in IPsec client, or if there are compatibility problems between the built-in client and the IPsec server, then a client installation may be required on user machines, increasing the administrative load for the network manager.
SSL VPN solutions are also based on a standard – Secure Sockets Layer – and in their modern implementation, they eliminate the need for a separate VPN client. Instead, the VPN capability is concentrated at an SSL server.
When the client requests access, the SSL server first provides it with the client software – this might take the form of a Javascript application downloaded to the browser of the user trying to access the network.
If the user provides the proper credentials, the SSL server will establish a VPN connection to the host. In general, packaged SSL-based VPN systems offer add-ons such as checking the security profile of the client system. This might include confirming that the user has anti-virus software installed with up-to-date signatures, that the latest operating system patches have been installed, and that a personal firewall is installed and up-to-date.
As with any security system, both IPsec and SSL VPNs are compromised by weak user credentials. If your password is easily guessed, then an attacker can gain access to the network. However, even in the mid-market, VPN products also support credentials management, from basic enforcement of stronger passwords, password storage in encrypted wallets on user machines, all the way up to token-based single-session passwords.
VPN All the Time?
Either of the two predominant VPN technologies are suitable for running inside the firewall, as security experts are now advising for wireless clients, but there are caveats.
Apart from the additional administrative expense and the cost of ownership of VPN solutions, the most important gotcha is the reliability of the sessions themselves. In their native form, encrypted VPNs are intolerant of interruption.
That's because VPNs are based on sessions. When the user disconnects, the session is ended – and the next connection happens from scratch (rather like using dial-up Internet, really. If you hang up, you have to dial again).
An ordinary wireless session may suffer momentary interruptions – brief loss of a signal, for example, or brief interference events – without the user noticing. The machine doesn't consider itself disconnected from the access point, and while there may be a packet retransmission happening in the background, the worst the user will experience is slower performance for a short time.
However, if the wireless client is running a VPN session, even brief interruptions can end sessions – something which will be very noticeable to users.
In most cases, the lost connection will be merely inconvenient: the user will have to reconnect the VPN client (and provide their credentials, whether a password or token) to resume downloading their e-mail or copying a file from the network.
However, the lost productivity may go far beyond inconvenience. For example, a database user running a long query will, if the VPN connection is lost, need to reconnect and restart the query.
So if you're going to use a VPN to secure the internal wireless connections in your business, it's important to protect clients against interrupted connections.
One way is to look for maximum coverage: build the wireless network to avoid all risk that the signal will be interrupted. The other is to look for VPN technologies designed for wireless environments. These may provide short-term caching of session keys to allow the resumption of interrupted sessions.
Either approach will have its downsides. Building a more extensive network of access points costs extra money, on the one hand; while on the other, most solutions for “session persistence” are proprietary, binding the customer to a single vendor.
Final Gotchas
It is, already, difficult to convince network managers that access points should not broadcast their presence to the network at large. Instead, any multi-tenant city office will be full of access points visible all the way to the street.
You also have to keep in mind that security client communications via a VPN does just that: it secures the client communications. To have a secure network, more is needed.
For example, the worth of the VPN is seriously undermined if a rogue access point can be plugged into a spare Ethernet port and get treated as if it were a legitimate connection. So even if you are running a VPN for all wireless connections, you still need port-level security that prevents unknown devices from connecting to the network without the proper authentication.