in message:
Date: Sat, 29 May 1999 22:03:10 -0700
From: "Ryan Russell" <[EMAIL PROTECTED]>
Subject: Re: DCOM on Gauntlet
<snip>
>We would still agree, wouldn't we (for some value of "we") that there
are
>some safe Internet services where examining the data is fruitless?
No. (Though, I don't know if I'm a member of the intended set
"we"). I don't know of one protocol that hasn't had an exploitable
client-side hole.
But, in many cases the assumption is most of the clients are
"safe" and/or you don't know what exploit to look for, so you
can't code around it anyway. I suppose the problem becomes
that when the exploit is later found, you then have to be able to
implement the full proxy, and the culture change may be
difficult.
Ryan
---------------------------------------------------------------------
What is also a problem is that once you have allowed a protocol through the
firewall, it is almost impossible to later restrict it. A protocol that was
fairly simple 5 years ago and had a reasonable security stance gets augmented by
bells and whistles for "multimedia interactive whizbangs" and suddenly you have
push technology, executable MIME, RealAudio over http and a real security mess.
For example our security policy forbids any protocol where a connection creates
a virtual circuit that can have initiation of data transfer from server end
(chat protocols are like that compared to normal http). But AOL Instant
Messenger can run over HTTP keeping open a channel that allows a full chat. It
is not just the exploits being found, but also the protocols themselves becoming
less secure (http/1.1 holds connections open compared to http/1.0).
Perhaps having RFC's define a proxy (or a ASN.1 -> proxy compiler) before being
accepted as a standard would help.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
