[VPN] SSL "VPNs"

Thu Feb 6 13:00:44 EST 2003

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

Keith 

-----Original Message-----
From: vpn-admin at lists.shmoo.com [mailto:vpn-admin at lists.shmoo.com] On
Behalf Of Tina Bird
Sent: Thursday, February 06, 2003 2:00 AM
To: vpn at lists.shmoo.com
Subject: [VPN] SSL "VPNs"

My sense of morbid curiosity got the best of me this afternoon, so I've
gone through the Web sites of three vendors who provide SSL-based remote
access.  The general idea for each of these is that SSL is used to
create a proxy connection between a remote machine and an internal
application of some sort.  This is sold as being more convenient and
less expensive (in terms of support and software) than a "traditional"
VPN solution because SSL is ubiquitous, available to any client
independently of operating system cos' it's implemented in Web browsers.

Alas, it's not this simple.  A traditional Web browser presents HTTP and
SSL data (and maybe FTP and gopher) to a client.  Web browsers do >not<
normally intercept network calls from non-Web applications (like
Outlook, or a database app).  In order to provide access to other,
non-Web protocols (like our favorites, the Microsoft networking
protocols, or an email server), the SSL-based systems have to create a
mechanism for intercepting those network requests.

This is typically done via a Java applet downloaded to the remote
machine when it connects to the SSL VPN server; or via a client
application that must be specifically loaded onto the remote machine.

But as soon as either of these client-side apps are required, you lose
the advantage of the SSL VPN in the first place -- you're managing
software on the client side.  Java doesn't help -- most of the support
people I know who deal with mixed Windows/Mac/UNIX environments
constantly struggle with inconsistencies in Java implementations.

The only applications that any of the SSL VPN vendors claim to be able
to secure without any code being loaded on a remote client are
>>Web-based applications<<.  Uh, hey, wait a minute -- I can turn on SSL
on my Web-based application servers and do that myself.

[In case it's not >>perfectly<< clear by now, I wasn't terribly
impressed by any of these solutions!]

Details below for specific comments and questions on the three vendors I
"reviewed."  My requirements for the solution are: it must be able to
support arbitrary custom database applications; it has to do granular
user based access control (they all satisfied that requirement); it must
contain the equivalent of "no split tunneling" or some other mechanism
for defending against piggy back attacks (none of them did that).

Neoteris http://www.neoteris.com

1) tbird's favorite bit of clueless marketing speak from web site:

"Since the IVE provides a robust security layer between the public
Internet and internal resources, administrators don't need to constantly
manage security policies and patch security vulnerabilities for numerous
different application and Web servers deployed in the public-facing
DMZ."

---> I'm going to buy a security product from a company that thinks I
don't have to patch my servers if I use their gear????

2) Implication from their architecture high-level overview is that a
"protocol connector" is required on the SSL VPN server to communicate
with internal applications (the equiv in firewall terms of an
application proxy).  There are not going to be protocol connectors for
custom applications.  They specifically mention protocol connectors
>for< MS Terminal services, MS Exchange, Lotus Notes, SMTP (may also
include IMAP and POP, it wasn't clear), VT100 and 3270 apps, documents
on file servers, Web-based enterprise apps, and *ooh* Intranet Web
pages.

3) Claims that Java-based application proxy can be used to connect to
proprietary client-server apps -- but see caveat above; once we're
dependent on Java we get into a multitude of support issues.  And
anyhow, they don't clarify exactly what "proprietary client-server apps"
means.

4) On the plus side, they seem to do very good system logging -- they
specifically mention that they log administrative changes as well as
user activity, which is rare and very pleasant.

Aventail http://www.aventail.com

1) Three remote access methods: browser-based allows access to Web
applications and file shares; downloadable applet for client server
applications (presumably also Java based); transparent agent for Windows
based systems only.

Not much more information on Web site.  Previous incarnations of
Aventail product were TCP-only, not very flexible.

Alteon http://www.nortelnetworks.com/alteon

1) tbird's favorite bonehead bit of Web site:

http://www.nortelnetworks.com/products/01/alteon/sslvpn/techspec.html

which purports to be the product technical specifications, but has no
technical specifications and at least one gratuitous grammar error.

2) Like Aventail, offers clientless access mode (for Web applications
only); enhanced browser mode (which isn't explained); and
device-specific client access mode for access to legacy applications.

3) And boy oh boy was >this< annoying: they discuss all the great things
you can do with their device specific client, but they don't tell you
what operating systems are supported with their client...

4) Also claims that it supports SSL encrypted connections to internal
applications, but this just perplexes me -- surely that only works for
internal applications that are SSL aware?

None of these vendors claims to address the split tunneling issue; none
of them offers convincing evidence that they can route arbitrary
IP-based traffic to an internal location, which I believe is a necessity
in most environments.

So, oh esteemed mailing list, anyone out there use these things?  If so,
what do you use them for, how do they work?  I would love to be able to
offer a "simpler" solution than, for instance, IPsec, but I remain
unconvinced that this is it.

Yours in the quest for more humor in the office -- tbird

-- 
I, on the other hand, do not work. I enjoy the slothful life of an
artist, and while away the hours in meaningless aesthetic pursuits
punctuated by bouts of hedonistic debauchery and an occasional nap.
                                              -- David Rinehart

http://www.shmoo.com/~tbird
Log Analysis http://www.loganalysis.org
VPN http://vpn.shmoo.com

_______________________________________________
VPN mailing list
VPN at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn