Re: [fw-wiz] The Outgoing Traffic Problem

-----Original Message-----

Message: 2
Date: Mon, 17 Jul 2006 09:52:24 -0400 (EDT)
From: "Paul D. Robertson" <paul@xxxxxxxxxxxx>
Subject: Re: [fw-wiz] The Outgoing Traffic Problem --
To: "Marcus J. Ranum" <mjr@xxxxxxxxx>
Cc: firewall-wizards@xxxxxxxxxxxxxxxxxxxxxxx
Message-ID: <Pine.LNX.4.44.0607170944000.11581-100000@xxxxxxxxxxxxxxx>
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
interesting question. Once you've got a user base that is accustomed
be being able to send arbitrary encrypted streams out through your
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,

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

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

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. :)


firewall-wizards mailing list

Relevant Pages

  • SSL and IPS (was RE: ssh and ids)
    ... How many simultaneous SSL sessions can be tracked?" ... I assume you're talking about a case in which the client constantly ... If you walk the possible session id space and ... The server chooses the session ID, ...
  • Re: IIS6.0 + SSL Breaks down!
    ... Ok, I asked the IIS SSL developer, and he gave me the details. ... bad public specification on SSL make SSL Client Certificates ...
  • Re: Can SSL sessions be compromised?
    ... etc) attachments using webmail during these SSL sessions. ... who the client thinks the server is ... ... part of this has to do with the fundamental digital certificate and PKI ...
  • Re: OpenSSL read/write timeouts
    ... This is an example of a SSL client with minimum functionality. ... This SSL client verifies the server's certificate against the ... the SSL server does not request & verify the client ...
  • Re: Using SSL with IIS 5.0 - how does it work.
    ... Description of the Secure Sockets Layer (SSL) Handshake ... username and password when users authenticates to server (e.g. to check ... his/her e-mail) (client sends this data to the server) ... If you want your users to trust your SSL certificate ...