Linux.com

After spending several days installing and configuring OpenS/WAN, I went looking for an alternative. Installing brittle kernel hacks in order to get my VPN up and running just didn't seem right. "It can't be this hard," I kept saying to myself.

I had the feeling you get when you go through some horrible installation procedure (Oracle) and wonder why it had to be so ugly, when all you need to do to install something as complex as Apache is ./configure; make; make install. I'm not ignorant to the fact that IPsec VPNs are kernel-coupled, and Apache runs as a user space daemon, but as a user and administrator, I just don't care. I want a product that installs easily, isn't brittle, and is straightforward to configure. I was sure there must be a better way, and fortunately there is: OpenVPN.

I stumbled across OpenVPN at the perfect time, the summer of 2004. They had just released a client for Windows and were about to finish version 2.0 -- which included robust centralized client configuration, and more powerful traffic-shaping tools. The installation looked simple, and the security was based on the tried and true SSL/TLS libraries. It seemed like it was worth a look.

I did some research and found the famous VPN article by Peter Gutmann which slammed the rest of the open source VPN market, but singled out OpenVPN as a potential winner. I dug deeper. The install instructions made my heart leap, ./configure; make; make install. The hook was set. The deeper I got the happier I became. Finally! An open source replacement to IPsec VPNs that provides the same feature set, plus some sane additions, but doesn't carry the kernel-coupled complexity that makes traditional VPNs such a headache.

A look at OpenVPN

OpenVPN uses the SSL/TLS libraries and structures to manage its cryptographic layer. The dual authenticated SSL/TLS key agreement/exchange method is almost identical to IPsec's Internet Key Exchange (IKE), and OpenVPN implements a tunnel system like IPsec's Encapsulating Security Payload (ESP) that has equivalent or better security to our venerable standard. The crypto algorithms available to OpenVPN include all the heavy hitters you know and love, with the default setting of RSA authentication, Diffie-Hellman key agreement, HMAC-SHA1 integrity checks, explicit IV, and symmetric encryption using Blowfish in CBC mode -- an excellent stable in my opinion.

What does all this mean to the layman? It means OpenVPN is able to create and maintain tunnels with at least the level of security found in the best IPsec implementations. This is important. There's a reason people have tolerated IPsec for so long, because it provides the gold standard for device-to-device communication over untrusted networks. OpenVPN matches this standard and takes it a step further.

Before we move on, I want to take a second to be really clear about one point. There is a terrible misconception that any product labeled "SSL VPN" is not a real VPN, and only provides some sort of bastardized access using a standard Web browser. IPsec provides what is commonly referred to as "network extension." This means exactly what it sounds like -- you extend your private network to include machines that are outside your local network's circle of control and likely will need to cross untrusted networks to reach your LAN. To accomplish this and maintain a sane trust model, IPsec VPNs require administrators to install a client component on machines that need to participate in this extended network.

OpenVPN uses the same architecture. No differences, no tricks. OpenVPN requires client installation just like IPsec, and this is a good thing. OpenVPN makes the client issue less painful by providing easy-to-install clients for Windows, Solaris, Linux, BSD, and MacOSX. (Let's see your Cisco or Checkpoint VPN do that!) But the real point here is that OpenVPN's network extension architecture is exactly the same as IPsec devices.

Many of the so-called SSL VPNs emerging lately tout their "clientless" architecture and claim you can get VPN access using a simple Web browser. This has serious security implications that we've already covered, but it also has feature limitations. Many of these products are just doing port forwarding, Web proxying, or "Webalizing" of protocols on a one-at-a-time basis, not true network extension.

I think we all know that it's not a very robust solution to handle protocols one at a time. What happens next week when a new cool protocol comes out that you want to run over your VPN? IPsec, and OpenVPN, handle network extension on a link level basis and can allow all protocols, all traffic, to traverse the VPN tunnel.

The real magic in OpenVPN is accomplished by its altered design paradigm. Instead of a kernel module, OpenVPN is implemented as a user-space daemon. Network interface access is managed using the virtual TAP/TUN drivers that are standard fare in most modern operating systems.

This simple change enables a host of flexible features and security improvements that leave IPsec in the dust. The two most important options by far are the ability to downgrade the server's privileges to user nobody, and the option to chroot the server daemon, both meeting our security philosophy of the principle of least privilege.

With every compromise of an IPsec process, you get a free root shell. Not a bad deal, eh? If you happen to find a way to crack an OpenVPN instance, all you get is an unprivileged user trapped in a fairly sparse directory. This is a big improvement in my mind. Many clever folks out there may eventually be able to wiggle free of this restricted environment, but it will take some time, time I can use to detect and react to your breach. Instant root shell à la IPsec doesn't give me any breathing room or protection even from less talented attackers.

Protection from worms

Not only was I impressed with the security OpenVPN provides for the present, but I also discovered another very interesting feature, future worm protection. What makes a vulnerability "wormable"? Well, you want a remotely exploitable vulnerability that can be automated and implemented efficiently and provide a useful level of access into your target system so you can access OS tools to further propagate the infection. You also want a large homogenous installed base of machines that are all vulnerable to the exploit so you get the most bang for your buck. Who wants to write a worm to infect 10 machines? No one, it's just not economical.

The OpenVPN designers realized this and put a great option into OpenVPN to diffuse the standard worm attack, tls-auth. What this option does is allow you to designate a key that all your VPN clients and servers must have in order to even start the SSL/TLS handshake with another OpenVPN instance. This key is unique to each OpenVPN administrative domain, making every OpenVPN installation different from every other one. So instead of having two million Windows 2000 machines that your worm can target, you now have clusters of 10, 50, maybe 100 OpenVPN instances that are similar enough for you to write an automated attack against. This feature won't stop determined attackers who are targeting you specifically, but it dramatically reduces the threat of automated worms.

Most of the above security controls are turned on by default or included as strong suggestions in the installation documentation.

And it's not all about security. I've already mentioned the ease of initial installation. Configuration is just as straightforward. One config file controls the server with a typical format we are all used to using in other open source products. Client configuration options can be set and controlled centrally using the --push and --pull directives.

Failover to multiple OpenVPN servers can be achieved with multiple --remote directives, and traffic-shaping and Quality of Service (QoS) options are also easy to implement. Authentication can be done using a variety of methods with X.509 certificates being the suggested method, and most common. User passwords, smart cards, and static key setups are also available for a variety of security levels ranging from good to great.

One feature I find appropriate and useful in a VPN is a reasonable level of routing and access control. Most SSL VPNs take this to an extreme level, but OpenVPN provides simple-to-use routing functions that can be assigned to specific users, and groups in the not-yet-released 2.1 version, to provide a flexible network architecture for partitioning remote access and directing client traffic.

If the command line gives you a stomach ache and you find OpenSSL hard to use, OpenVPN provides a suite of graphic tools to help install and administer an OpenVPN environment. The My Certificate Wizard and OpenVPN GUI are two great products that shield the weak at heart from the gorgon of the command line interface. Other graphic tools can be found on the OpenVPN Web site.

Maybe you just love recompiling your kernel on a regular basis, and have the time to sit in the server room and babysit your VPN machines to achieve sub 10 second incident response. If that's the case, IPsec may be the thing for you. Or maybe you're just looking for a cool remote access tool that doesn't really worry about security. If so, one of these alleged SSL VPNs may be right for you, although I don't think they are right for any organization with even one bit of confidential data. But for those of us who want an intelligent, easy-to-manage VPN that provides robust features with industry strength security, OpenVPN is the clear choice.

Share    Print    Comments