[Anyone remember the story about PIX, MS Exchange and TLS? *smile*]
On Wed, 1 Mar 2000, Frederick M Avolio wrote (in reply to my message)
> What I would like to see (and this is able to be done, without
> reinvention), is a description for each service that indicates the level of
> analysis.
This is what I was aiming at. Let's abandon the term "application
level" and have everyone describe -- exactly -- what they are doing.
> There are some services that are so close to impossible to
> analyze, that they might as well just be transport level (circuit)
> gateways. Video streams come to mind Others (FTP), should be more closely
> scrutinized.
In times of "closed" protocols, where there is a good chance (after asking
very very hard, a tech said 'yes, this we could do in the first
versions') that one of the most widely used protocols for playing
streaming audio could tranysport the code which would decompress the
audio, too... (ok, I apologize for spreading FUD, but this paragraph is
not made up. There is a certain amount of truth in it...)
> >An WWW Application proxy should be able to see the page which it is about
> >to deliver to the client. It should be able to strip any, all, and
> >everything which could harm the client application.
>
> Practically speaking, an application gateway can do this modulo "the
> halting problem." So could a SI firewall. "Could" is the key word. Not all
> firewalls of either type bother to do this.
The above quoted paragraph was enclosed into "#dream" delimiters because I
know this is impossible right now (well, not really. There are solutions,
but they are not used and/or usable in most cases). But I would urge the
vendor to tell me what his proxy is doing. Up front. Not post mortem.
Anybody found a https proxy which says "wait a minute! you can't do
this!" if I try to abuse it as a telnet proxy? And it should be easy see
the difference between an ascii data stream with interactive traffic and
and encrypted data stream with bulk paiload.
We are living in the sone ages of information security. It just needs some
time...
> >Trying to sell transport layer proxys by the name of application layer
> >proxys might be more common than most people think. I can't prove it right
> >here, but I have this feeling. I have this dream...
>
> It is incredibly common. Which is why I'd like to see a more detailed
> description in product descriptions. But, very few end customers actually
> care about this.
Very few have been told that there is a difference. And that the
difference counts.
Perhaps it's time to rewrite the FAQ? ;-)
andreas.
P.S.: Regarding the "halting problem", I have to admint that there are
times in which I prefer stream proxys. The more "knowledgable" the proxy,
the better the chance that someone finds a bug and a way to exploit the
bug. The worst thing is an application level proxy with an easily
exploidable buffer overflow. Unfortunately, bad things happen.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
