Re: The Outgoing Traffic Problem

["Mike Barkett" <mbarkett () nfr com>]

> -----Original Message-----
>
> Message: 2
> Date: Mon, 17 Jul 2006 09:52:24 -0400 (EDT)
> From: "Paul D. Robertson" <paul () compuwar net>
> Subject: Re: [fw-wiz] The Outgoing Traffic Problem --
> To: "Marcus J. Ranum" <mjr () ranum com>
> Cc: firewall-wizards () listserv cybertrust com
> Message-ID: <Pine.LNX.4.44.0607170944000.11581-100000 () bat clueby4 org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Tue, 11 Jul 2006, Marcus J. Ranum wrote:
>
> > So perhaps a bit of this message is "I told you so!" but it does raise
> an
> > interesting question. Once you've got a user base that is accustomed
> > be being able to send arbitrary encrypted streams out through your
> firewall,
> > what ARE you going to do when the bad guys start tunnelling in with your
> > "authorized" data?
>
> IDS!  No IPS!  No SSL Firewalls!!!!!
>
> We're way beyond the generic protection mechanism stage, simply because
> HTTP tunnels have driven us there.  SSL tunnels won't change that, so
> here's your next big great market opportunity...

The definition of "generic protection mechanism" is a moving target.  You're
probably right that there is an opportunity here.  One or two steps ahead of
this, it would not be unrealistic to see some host-based information leakage
clients popping up as NAC components.  i.e. you only allow NAC-ok'd traffic,
and the NAC client enforces info leakage policy, as well as some anomaly
detection on encrypted traffic.  Same sabotage implications as AV software,
but with a sentient and authoritative network presence.
 
> > In Marcus-land, it seems an act of insanity to allow
> > (anyone inside) -> (anyplace outside)
> > SSL connectivity. For exactly the reasons that State appears to be
> > in the process of discovering.
> >
> > What are most organizations doing about this?? Do most security
> > managers have their heads still firmly in the sand on this topic?
> > I trust that everyone realizes that it's going to get worse, not better,
> > right?
>
> Most security managers have their heads firmly planted somewhere- normally
> it's in a vendor's sandpile ;)

With the rising price of oil, it is getting increasingly expensive to
transport truckloads of sand to customer sites.  Nowadays, usually it's a
Webex PPT containing several slides with pictures of excessively sandy
tropical beaches into which the customer might one day be able to lodge
his/her head.


> > As far as I can see, the endgame is going to be one of two
> > things.
> > - Organizations are going to try to add signature-style
> > controls to SSL transactions and are going to rely on "man
> > in the middle" style interception tricks and (call 'em what
> > you want) signatures to detect malicious traffic
> > - Organizations are going to have to positively identify
> > sites with which it is necessary/appropriate to do SSL
> > transactions
> >
> > I don't see a lot of future in EITHER of those options. The first
> > one falls apart really fast if anyone ever fixes SSL's certificate
> > trust model (not highly likely) but since it's signature-based
> > it'll fail when the hackers add superencryption to their command
> > streams. The second option would have worked if it had been

It also requires the man-in-the-middle to proxy the public keys of every SSL
site visited.  S-L-O-W!!!!  Nevertheless, I'm sure many people will
voraciously pummel this problem with this cotton hammer for a few years, to
no avail.

On some level, I wonder why nobody ever uses the client authentication
features of SSL that have been around forever.  I mean, I know WHY, but now
we are paying for it.  IMO, if every client had to use 2+ factor
authentication to visit any SSL site, via client SSL proxy, it would at
least reduce this problem to a level of manageability consistent with
today's worms.  Again, slow, but maybe the only easy stopgap until The
Ranum-Robertson Corporation opens its doors for business.


> > approached 10 years ago but ironically there's finally enough
> > SSL being used that it's probably too late. And reining it in
> > would be bad, anyhow. So what happens? Is the long term
> > prognosis as bad as I think it is? I'm just afraid that the
> > hackers, malcode-writers, and botnetters of the world are going
> > to have an impact on the entire Internet that is comparable to
> > the impact that the spammers have had on Email systems:
> > namely, they have degraded the value and raised the costs
> > of the system to the point where it's worth 1/100th of what it
> > should be. As many of you have noticed, this boils my
> > blood.
> >
> > Someone, please - tell me I am wrong and that somehow
> > it'll get fixed soon.
>
> I dunno- wanna form a software start-up?  I've got a couple of ideas.  Our
> motto could be "We sell you expensive stuff because your were too stupid
> to listen to us when it was a cheap problem to fix."

I know a few people that could help with this.  The marketing angle, in
particular, could probably use a touch-up.  :)

-MAB

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards