Sorting Through the Hype of Ubiquitous Secure Remote Access and SSL VPNs

{LANG_NAVORIGIN} Encryption VPN
Ken Salchow 03/12/2005



[1]Main Entry: ubiq·ui·tous
Pronunciation: yü-'bi-kw&-t&s
Function: adjective
: existing or being everywhere at the same time : constantly encountered : WIDESPREAD
- ubiq·ui·tous·ly adverb
- ubiq·ui·tous·ness noun

Introduction

If I told you that I could give you a car, exactly like the car you already own with the exception that it gets 1,000 miles/gallon and would have no maintenance costs for 10 years, would you start asking me about adding cup-holders? I doubt it—I sure wouldn’t. However, if I told you that I could replace your existing remote access solution with one that provides the exact same capability, but has increased deployment flexibility, increased security options, a lower TCO and faster ROI—I am constantly questioned about whether it can provide “ubiquitous” access. The short answer is “No.” The real answer is “No. You shouldn’t expect it to, don’t really want it to and don’t really need it.”

Since the days of the first off-box SSL termination solution, I have been contemplating, what at the time I referred to as, the “poor man’s VPN”. Of course, if I had put any real imagination into it, I would be writing this from my retirement villa in the south of France instead of my cubicle, but that’s neither here nor there. The idea back then was that I could access any resource that could be tunneled through an SSL connection from my corporate owned resource without fear of it being intercepted as it traversed the big bad Internet. We played with things like FTP-s and Telnet-s, etc., and as long as we had a client that supported the SSL negotiation, we could use any generic SSL termination box to decrypt the traffic and send it on its merry way to the appropriate backend resource. It worked like a dream and dramatically increased our ability to remotely administer networks without being compromised by the in-security of the channel. While this wasn’t an “officially” sanctioned remote access solution and rarely had any strong authentication requirements apart from those of the actual backend resource, it was reasonably secure, protected us from eavesdroppers and still required a fair amount of knowledge—as well as specialized software—to make it work.

Today’s world is a whole lot different. SSL-based VPNs are now all the rage from the Fortune 1000 down to the mom-and-pop business—redefining the ease and ability to remotely access resources that were previously only available via IPSec technologies, which often carried their own overhead and problems. This new breed of SSL VPN is far from a “poor man’s” solution, many of them providing full layer 3 connectivity to the remote network. Gone are the days of specialized software and potentially complicated client configurations; all one needs is a standard web browser and support for Java or ActiveX. This full featured capability, coupled with the extreme ease of use, has opened the floodgates of ideas about how to exploit this to its full potential—and this usually leads to the concept of “ubiquitous” access. Unfortunately, it isn’t that easy, and this concept of ‘ubiquitous” secure remote access—remote access from anywhere on any device--is, in my opinion, mostly a pipe-dream useful for theoretical thought, not real-world requirements. I can think of at least three reasons why ubiquitous secure remote access will never, or more probably shouldn’t ever, happen; technology, security and business requirements.

The Technology

The first issue with ubiquitous access is the wide range of technology that we must deal with in the real world. There are essentially two methods available today to provide remote access capability. The first, more traditional one used by IPSec as well as many SSL VPNs, is to create a secure “tunnel” through which to send traffic between the remote client and the host network device. The second, unique to the SSL space, is to use a proxy to mediate the traffic between the remote client and the host network device. These methods provide varying degrees of functionality and varying degrees of security depending on how they are employed.

Most vendors, including the traditional IPSec vendors who have entered the SSL VPN space, are referring to some type of “proxy” access when they talk about SSL VPN. In essence, the SSL VPN device acts as an SSL terminating reverse proxy, allowing you to access already web-enabled (http/html) content directly from the Internet over an SSL encrypted session. Not to belittle the functionality of these offerings by simply calling them “reverse-proxies”, many can provide advanced features like ActiveX and Java Byte-code rewriting and resigning on the fly as well as some protocol specific proxies, allowing them to provide a greater range of access than a simple reverse proxy. The downside of this method, however, is that apart from a centralized authentication system to provide access to multiple resources and more “depth” in your security posture, these systems don’t provide much more than you would garner from making the actual resource Internet accessible behind a firewall and using the built in SSL capabilities of the native web-server hosting the application. Even more constraining is the fact that advanced web content is increasing difficult to mediate with a proxy engine and the fact that, no matter what you do, a proxy cannot change the fact that the accessing browser may not support that advanced content; “any” browser may not be sufficient.

The more interesting of the two methods is the use of either port-forwarding or a full layer-3 tunnel approach which provides IPSec-like connectivity without the pre-installed client. While these were once called “clientless” VPNs, the moniker has mostly been dropped because all of them require some sort of client-side code to operate, the difference being that most (but not all) provide this client dynamically at the time of access instead of having to be pre-loaded and configured—and the client-side configuration is minimal at worst. This method of remote access provides for any type of resource access (ftp, telnet, terminal-services, file and print, etc.) all without the need for specialize fat clients (like the good old days) and can be a drop-in replacement for most IPSec solutions. In addition, because the client is dynamically installed and updated, deployment time and costs are generally much less than its IPSec cousin. The downside to this method is that in most cases, because of the need of driver level integration to create the tunnel, this method has restrictions on both the OS that can be used and the amount of system-rights the user needs to install the software.

It should be apparent from even this basic information, that the idea of “ubiquitous” access is greatly over exaggerated. In the case of the proxy-based access, you can access resources from virtually anywhere, but you can only access web-enabled content or content that a specific protocol proxy has been written for and every change in even those applications will require adequate testing before deployment. With the tunnel access, you can access virtually any resource, but you can only access it from a supported OS where you have appropriate rights to install the software dynamically—although many vendors support a pre-install capability. Combined together, these provide a wide range of access choices, but choices have to be made and it is difficult to educate end-users to correctly identify the appropriate method on their own. All of this goes to show that truly ubiquitous access should not be expected and can not be delivered in the current state of technology.

















Your IP address will be sent with this e-mail

From e-mail to e-mail