To combat the potential security nightmare of allowing remote users through a corporate firewall, Virtual Private Networks (VPNs), are based around technology that ensures strong authentication and encryption.
The standard Windows VPN protocol is the Point-to-Point Tunnelling Protocol (PPTP), but there’s also a non-Microsoft standard in the form of IPSec. Both of these approaches work in similar ways, in that they set up a ‘tunnel’ between the client and the remote network through which all traffic is passed (and encrypted/decrypted at each end). When one end requests that a tunnel be set up, both parties embark on a process of checking each others’ secret keys (the private authentication codes that allow definite identification of each endpoint), and once the tunnel has been set up, encryption protocols such as Triple-DES are used to ensure that no plain-format data goes through the tunnel.
An end to hand-holding
Although widely implemented, IPSec’s main drawback is that it’s a pain to configure both the server and the client, as it involves configuring lengthy key pairs. This means that setting up a remote user’s PC is either a tech support task or, at the very least, a long-winded hand-holding job for a techie trying to lead the end user through the process.
Is there not, then, an alternative protocol we can use to connect remote users to office-based services without compromising security but with much less setup complexity? The answer from an increasing number of vendors (and certainly favoured by analysts such as Gartner) appears to be Secure Sockets Layer (SSL).
SSL is the protocol used by secure websites to guarantee a secure, authenticated connection between a browser and the website. It’s built into Windows as standard, it’s part of Internet Explorer, and there are both commercial and freeware implementations of SSL libraries available for most platforms.
SSL uses the concept of ‘certificates’ for the authentication of the two ends of the link and, as with IPSec, encryption is also part of the standard. Unlike IPSec, which simply sets up a tunnel between the two endpoints through which several applications communicate, SSL is an application-specific concept: so a Web session might have one connection, a terminal session might have a second and an FTP link could have a third. Neither approach is necessarily better than the other, because with IPSec you have to police the tunnel at the firewall, and with SSL you need to ensure that the firewall does not allow unwanted connections to be created in the first place.
One of the approaches being suggested for SSL-based VPNs is to forget the idea of having a client application, and instead operate on a thin-client basis. So the user connects with an https://… connection in their browser to a proxy-cum-application server at the office in order to read his email, browse the network, edit Word documents and so on. In our mind, though, this isn’t a real VPN; it’s little different from giving users access to (say) Outlook Web Access and turning on SSL – it’s a useful thin client tool but no good for people who want to use their real applications from afar to contact the company’s main servers.
The next step up the ladder, then, is to embed SSL capability in the applications at the client end so that they communicate directly with the proxy server at the office end; this is more realistic, and in fact many applications are already SSL-enabled (secure terminal clients such as SSH applications support SSL, for example, as do email packages such as Eudora). It’s not a great leap of faith to expect the operating system IP stack writers to include idiot-proof API calls before long, too, which will enable simple inclusion of SSL in desktop applications.
Policing the connection
The main issue with SSL, actually, is at the server end. With IPSec, you’re opening a tunnel between the client’s IP driver and the firewall; with SSL you’re making an end-to-end connection between the client’s application and the application inside the remote network. You therefore have the issue of how to police the connection at the firewall.
The main problem is that if the firewall allows the SSL connection through from source to destination, it can’t police its contents because the contents are strongly encrypted. It can potentially do some certificate checking and can verify in the directory service as to whether that application under that user’s ID is allowed to attached to that service on that server, but once the connection’s established it can do no more.
This may, of course, be fine for many installations, but if not then the alternative is to adopt the proxy approach mentioned earlier. The idea is simple: encrypt the connection between the client and the firewall, and then allow the firewall to act as a proxy for the portion of the link inside the corporate network. Although this means implementing proxy servers, it’s not a big deal because it’s well-understood technology; most firewalls have a pile of proxy servers for the main protocols such as SMTP, FTP, Telnet and such like, albeit aimed at internal users making outgoing connections so it’s a trivial job to turn the connection around and have them work on incoming connections.
It seems that SSL stands an excellent chance of taking over from IPSec for user-to-office connections, simply because it’s easier to use without compromising security and there are ways around the fact that it’s an application-to-server link instead of a tunnel. IPSec is not dead by any means, though, because it still suits the network-to-network type of connection. Okay, it’s a fag to configure but that’s not a problem for the network manager who (a) understands how to do it and (b) probably only has a handful of sites to deal with and hence a small number of configurations.
A tunnel is exactly what you want from site to site, and an application-to-application link most definitely isn’t. The same applies to small/home office users who have an external firewall/router instead of a PC-based security/VPN installation – the reason these people have external gadgets is because they need a tunnel. But when it comes to remote clients with a handful of PC applications and occasional dial-up connectivity, SSL has the potential of bringing support costs down. We shouldn’t be surprised if its installed base grows rapidly in future.