Linux.com

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...

Share    Print    Comments