NetSec Letter #24, 7 February 2003
SSL VPNs

Fred Avolio, Avolio Consulting, Inc., http://www.avolio.com/

In NetSec Letter #14 (www.avolio.com/columns/14.html), I stated, "The year 2001 will be remembered as the year of the VPN." I then went on to point out that I said the same things about 1998 and 1999. VPN usage did rise, due to the rise in remote access requirements pulled along by the increase in high-speed Internet access available to teleworkers and work-extenders, and by the maturing of the base technologies that provide VPNs. Most of us are somewhat familiar with IPSEC (which I have decided to start spelling as those who named it do, in all CAPS). In the last year another class of VPN has grown into an interesting, and separate, market segment: the SSL VPN. This month, I want to make a case for SSL VPNs. [Disclosure: Aventail Corporation, a maker of SSL VPNs, recently hired me to write a white paper. This is NOT it. Also, in the past Whale Communications paid me to evaluate their E-Gap Server, which also provides SSL VPN functionality. This is also not it. But I did want you to know all this.]

Definitions

I suspect that everyone reading this is familiar with SSL. You use it with your browser when making a secure transaction (sometimes). The web storefront -- the http server -- sends a digital certificate containing a public key, your browser verifies the certificate (and so, the key) as valid, and uses public key cryptography to make an encrypted connection back to the server to decide on secret keys to be used for confidentiality, authentication, and integrity checking. (See "Cryptography 101 at http://www.avolio.com/columns/Crypto101.html for more details.)

This is an SSL connection, but is it an SSL VPN? No. Neither is an IPSEC connection a VPN. Let me explain. A VPN should provide the basic communication security features of confidentiality, authentication and non-repudiation (as if anyone cares about this), and integrity assurance. Add access control and you have a VPN. An SSL VPN, as opposed to an IPSEC VPN, uses SSL for the secure communications piece, and must add access control.

Access Control

Access control is important. Just because a connection is secure, doesn't mean it is safe. All it means is that it is difficult to impossible to hijack or intercept. A legitimate user may have access rights to all sorts of things when sitting at his desk, on a known network address. Your security policy should stipulate how access rights change based on the connection point of the user. Is he at home or on the road on a company-owned PC? If he has a VPN client -- software that allows access after some kind of strong and protected authentication to the PC -- perhaps his access rights are similar to when he is at his desk at work. Is he at the local Starbuck's on a wireless LAN? If it is his same PC, you still might want to trust the connection. Being wireless does not affect "the equation." Maybe his connection is from an Internet Cafe, or a PC at a computer conference. What then?

Well, it depends. It depends on how much my VPN server can tell about the client PC. You might want to know if it is running a PC firewall or antivirus software. It will also depend on security attributes, such as key size, key algorithm, and authentication methods available (a user name and password over an encrypted connection is safe from eavesdroppers but not from guessing, whereas a challenge/response system or security token allows for a higher level of assurance).

An SSL VPN should provide the following:

  1. Allow users to access what they need, from where they need it, without compromising security. What they need and what they want are two different things (and you've read comments from me on this subject before, I hope). Some SSL VPNs only allow access to applications that are or can be "webified." This may not be sufficient for some users in some environments. Aventail and Nortel (and I am sure a bunch of others -- do not write to complain that I didn't include your company, but do write to inform me) provide thin clients -- Java applets downloaded when needed -- to access other applications.
  2. Robust authentication mechanisms that do not compromise security (but rather enhance it) and allow you to use a variety of mechanisms, such as tokens, digital certificates on notebook PCs or on smartcards, and even RADIUS servers if needed.

Why I Like SSL VPNs Best

There are three reasons I like SSL VPNs best. First, they are less expensive to deploy than IPSEC VPNs. They do not require an expensive PKI (an oxymoron) in order to operate securely. They do not *necessarily* require touching everyone's notebook PC in order to install a client. They do not require everyone to have a corporate-owned PC.

Second, they allow access on the fly, from other people's offices, kiosks, anywhere.

Third, they operate at the transport layer rather than the network layer. This helps for ease of use. The SSL VPN server makes security decisions at the transport or application layer. This has implications that are significant, and have been personally significant to me. I have a satellite connection to the Internet (Earthlink, via DirecPC), which is fabulous if it is your last resort. I've tried unsuccessfully to use some standard and well-known VPN clients in the past. Even after the IT department surrogate (I was half of a demo, and also needed it to write a column) set up the client, pre-loaded it with the security policy, postal-mailed it to me, and I installed it, it would not work. All sorts of NAT and other anti-IPSEC stuff were going on. I even thought, "Perhaps DirecPC denying packets, as do some other ISPs. But no, that is not the case. Recently, I had to use an IPSEC client to access secured information. The server-side of things still had to ship me client software on a CD, but after installation, everything worked fine. Even, better, I was able to easily access the Aventail demo lab using no client (just secured web access for webified applications), the thin client (installed on demand, like any Java applet), and an access client (securing all permitted network traffic, and denying that which is not permitted). What more could I ask for?
#

Promotions, Self and Otherwise

My 2003 calendar is finally up on my web page. Please see www.avolio.com/calendar.html. Please note I will be speaking this Monday in Scottsdale, AZ, at MIS Conference on Mobile and Wireless Security. The 1 day class is VPN Introduction and Best Practices. I will be in New York City on February 19 for a private 2-day class, "Investigative Response." Even though you cannot get in to it, I mention it because I think it is one of my best classes and encourage you to see if it might not fit into your corporate security training. It is a workshop to walk you through developing an incident response plan and first responder team. If your company needs such a team (all medium and large companies do) and do not have one (many do not), consider kicking it off with this class. See http://www.avolio.com/courses/InvestigativeResponse.html.

Later in February I will be in Orlando to teach a new and improved "Tools and Techniques" for CSI.

My January Information Security Magazine "Just the Basics" column is entitled "Belts and Suspenders Redux," a look at making your router take some of the load. You can find it at http://www.infosecuritymag.com/2003/jan/justthebasics.shtml

I also have a feature article in the February issue. In "Gateway Guardians," I evaluate and compare 5 E-mail firewalls. See it at http://www.infosecuritymag.com/2003/feb/gatewayguardians.shtml.