Author: Charlie Hosner
When you are working with mature security technologies (like SSL/TLS), security is often a zero sum game. I realize that SSL VPNs are a new paradigm, but when you increase an architecture’s feature set, you almost always do it at the expense of security. It is possible to squeeze out small incremental gains, but when someone says they have bumped functionality way up without compromising security, you need to take a closer look to verify these assertions. It is possible to gain in both areas, as we’ll see when we talk about OpenVPN, but for the most part those kinds of claims have nothing but vapor and marketing push behind them.
The main architectural advantage of SSL VPNs is that they shed the complexity of IPsec in exchange for the simple, well tested SSL/TLS structure for their cryptographic layer. To this I say “Bravo!!” IPsec is a hard protocol to use effectively for a variety of reasons.
One, IPsec has too many possible configurations, some of which produce insecure architectures. The adage, “complexity is the enemy of security,” is well illustrated by this excessive group of configuration options and structural components.
Two, the nature of IPsec requires it to be tightly coupled with the OS kernel. This is bad for any application, but much more severe when we’re talking about critical security components. Since the days of Multics it has been well-known that in order to architect a secure, available system, you need to avoid interference with kernel space wherever possible. If your code can interfere with kernel space, its failure is usually catastrophic for the entire system. If your security code can interfere with kernel space, it can compromise your entire security framework with a single failure. Every compromise of a kernel-coupled component equals instant root access. IPsec VPNs are implemented in kernel space, SSL VPNs do not have this requirement. So, in theory, SSL VPNs are a great idea.
In practice we see this opportunity squandered in the name of selling more boxes. While some SSL VPNs are experiencing the gains I mention above, most are taking one step forward and three steps back by failing to adhere to many of the important architectural requirements of VPNs. The primary area of weakness is the notion of a “Clientless VPN.”
In traditional VPNs, a server runs the central VPN software and each client has a local application installed so they can participate in the extended network. This client application is pre-installed and pre-configured by an administrator and is done on a per-machine basis. Users can not connect from any old machine they want. They are limited to connecting from their pre-configured machine. The obvious area for improvement here is to free our belabored user from the tyranny of pre-configuration, and instead let them start a VPN session from any machine they happen to be using. While this sounds just dandy to the layman, the security implications of this are extreme.
We can not have secure communication unless we know who is on each end of the communication link. Having a pre-installed client on the user’s machine helps satisfy this requirement. Otherwise, it’s like having a cell phone that guarantees an encrypted link from end to end, but dials a random number every time you call someone. You know for sure that no one can eavesdrop on your communication, but you have no idea who you are talking to. Doesn’t sound very secure, eh?
Traditional VPNs vs. SSL VPNs
Traditional VPNs required trusted end points to function. The server and the client were machines with (one hopes) some elevated level of trust as our corporate administrator installed the VPN components on them personally, and covered both machines with the corporate security policy mandated controls. Additionally, authentication credentials were pre-installed on both of these devices so each endpoint could authenticate its peer and have a high probability of trust in the entity with which it was communicating.
SSL VPNs allow users to connect to the central VPN using any machine they happen to find. This includes their home machine, their kid’s laptop, a public machine in a coffee house, or a public kiosk machine in Eastern Europe. Two severe issues arise here. First, we break the trust model. The server and client no longer share a pre-configured trust relationship. Instead, they have to attempt to build something on the fly. Barring a user who is able to remember some 1024-bit RSA keys, we are going to have to do this with passwords. This opens us up to trivial to implement Man in the Middle attacks that are well-developed and available to even the least-skilled script kiddies. Now all our information is decrypted by our attacker and it is very difficult for us to detect the passive exposure.
The second issue is that our users are connecting from machines that are not subject to our rigorous (again, I hope) corporate security policies. Even if our user manages to start an SSL session with our actual server (instead of a Man in the Middle) they are still doing all their input and output on an unknown machine that might well be managed by people who specialize in making lattes, not computer security.
If they are connecting from a public machine that is under the control of an attacker, they will be exposed to keystroke loggers and remote management tools that allow our friendly attacker to sniff passwords, collect all data from our session, and even watch the graphic interface as our user works with our sensitive corporate data. Security is a chain which is only as strong as its weakest link. With “clientless VPNs” your weakest link becomes some random machine in some random location.
In a weak attempt to reduce the risk of our users connecting from insecure machines, some SSL VPNs include the option to verify that connecting client machines have virus protection and a firewall enabled. This is what Bruce Schneier likes to call “Security Theatre” — it creates the illusion of security, but doesn’t actually provide any increased protection. How do they verify whether the machine has virus protection and a firewall? Well they ask the client machine of course! This is tantamount to asking a criminal if they are a criminal. You can not ask an entity to validate itself, this is security 101. Additionally, if you go ask an attacker what the first thing he/she does when they crack a machine, they will usually respond with “update the system so it’s secure, and turn on a firewall so no other attackers will bother me.”
With IPsec, our users are restricted to only connecting from pre-authorized machines, but we have the advantage that these machines are trusted and known endpoints that we can authenticate. With the modern SSL VPNs, users can connect from a variety of machines, but NONE of them, not even machines that could have been pre-configured, are safe from Man in the Middle attacks. Just to keep the flamers at bay, some SSL VPNs provide the option of installing certificates on client machines to fix this problem. Hey, that sounds a lot like installing client software, plus certificates aren’t the default or even suggested configuration. Systems that are insecure out of the box are likely to be insecure in implementation — not everyone is a security expert and can understand the subtle ramifications of their configuration choices.
The second area of concern I have regarding SSL VPNs is the increase in their complexity. The very reason we want to move away from IPsec is to avoid its complexity. SSL VPNs are now including complex access control systems, intricate routing features, and a myriad of port forwarding, application proxying, and even file-sharing capabilities. Some of these features, authorization and routing, belong in a remote access solution, but many are overblown or just not appropriate for a VPN. The reason we moved away from “everything to everybody” type systems is because they usually don’t do everything right, and dramatically increase a hacker’s attack vectors.
In a file server, we can tolerate some slop, but in our most essential security devices, this is not acceptable. That’s why we have dedicated machines to handle VPN, firewall, routing, Web serving, email serving, etc. Many SSL VPN vendors have put us back into an environment where too many options are available to compromise our systems security. I saw one product that actually had a check box labeled “Allow Insecure Connections.” This is ridiculous to see in a VPN device.
I’m only doing analysis here based on architecture; I haven’t dug into how these SSL VPNs are actually implementing SSL/TLS. While I would say that some of these organizations (Cisco, Checkpoint, Juniper) should be quite adept at building crypto systems, the fact that they are missing the point on architecture makes me think they may be cutting corners on best practice crypto as well. Cryptography is tough to do right and variations as simple as the order that primitives are applied can totally break your security, as we saw earlier this year in broken IPsec implementations that would HMAC-then-encrypt instead of encrypt-then-HMAC. Time, and the reverse engineers, will tell.
The central flaw of most SSL VPNs is the variation in architecture that breaks the trust model necessary to provide the highest level of security, which most people equate with the label VPN. Security is a chain and the security of the entire system is only as strong as the weakest link. If the client is insecure, the entire system is equally insecure. The standard SSL VPN product has dramatically reduced the security requirements of the client machine in exchange for the flexibility to use the VPN from any device.
More on page 2…Part II: Good SSL VPN, good…
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.
Category:
- Security
