Date: Thu, 06 Feb 2003 13:00:44 -0500
From: Keith <>
To: "" <>
Subject: RE: [VPN] SSL "VPNs"

Never mind the vendor marketingspeak. Of course the vendors are make their product the "prettiest" out there. When have they NOT done that? Just make sure you do due diligence in validating vendor claims.

Interesting how the VPN market is fragmenting into these types of specialty categories. Certainly, SSL-based VPN is not appropriate as a replacement for every IPSec VPN out there. However, IPSec VPN does have its appropriate place, too.

Webmail is, currently, probably the most popular application for a "SSL-based" VPN. What's to prevent some one from subverting a telecommuter's webmail session today to, somehow, get into the internal network today? Remote desktop security management tools/techniques. i.e. personal firewall/IDS, desktop a/v, etc.

It could be argued that secure remote access does not come in a box with ANY VPN server product (IPSec included, sorry chkpt and csco). I would not be expecting it from these newer SSl-based box makers either any time soon, either. Most of newer SSL-based VPN folks observed how the earlier generation VPN companies got burned due to poor remote desktop security management capability in their clients, back in the day, and decided not to get into THAT conundrum.

There are 3rd party remote access security policy management solutions that enforce desktop security policy on the remote desktop before allowing connections and possibly can be adapted to work with SSL-VPNs (a 3rd party remote access policy enforcement agent check before establishing the SSL-based VPN connection, etc).

At this point in technology development stage it probably a good idea to look at the newer SSL-based as just a piece of the puzzle, from a remote access security architecture perspective. Use a knife for cutting, a fork for eating, hammer for building, SSL-based VPN for y, IPSec for w, MPLS-VPN for z...etc.. You get the idea.

I advise that, except in the simplest implementation, a network security assessment and desktop software audit should be conducted to discover what areas of the secured remote access pieces are missing. Anybody who would just install one of these boxes without doing this, will not
truly understand, therefore, be able to manage risk involved.