I don't think the security admin perspective will affect the industry trend
to bypass firewalls for networked apps -- unless all security admins decide
to open all ports to unrestricted access :-)
Vendors perceive firewalls as an impediment to selling their software(*).
A CEO/CIO might be able to order holes in firewalls; but many vendors sell
below that level, for various reasons. And those customers can't/won't ask
for holes in firewalls. Therefore, vendors design networked apps to
piggyback on the one protocol that *must* reach every desktop - HTTP.
Those same app vendors don't care about larger security issues. These
facts-of-life were explained to me by a good friend working on
CORBA-over-HTTP.
SOAP might use an explicit HTTP header, but lots of dangerous apps use
plain old HTTP. For example, I've seen several reports of email viruses
coming into enterprises via Hotmail accounts.
Relying on overloaded HTTP proxies to parse even deeper into each packet;
keep even more state; and make even more decisions; is not a path to
trustworthy, high-performance firewalls.
-- Rex
(*) Vendors *like* firewalls as soon as you point out that their
brain-damaged software is a security nightmare. "Well, you just have to
run it behind a good firewall", is the often-heard answer to
poorly-protected Web-based full administrative access to product X.
At 11:23 AM -0800 1/4/01, [EMAIL PROTECTED] wrote:
>An alternative scenario for the builders of app "Z" is is to use HTTP as a
>substrate for protocol "X", such as SOAP [2] does -- with the tacit
>expectation that the deployers of app "Z" will not be obliged to interact as
>closely (or at all) with their security administrators.
>
>But, as mentioned in [2a], SOAP uses an explicit HTTP request header field
>("SOAPAction") which one can use to filter SOAP traffic out of HTTP streams.
>
>So, it seems to me, layering app protocols such as "X" on SOAP-over-HTTP
>isn't
>necessarily a panacea for "going through firewalls" -- those of you who're
>running HTTP proxies will likely easily notice SOAP going through port 80,
>though in {some | many?) cases you'll have to configure stuff to explicitly
>look for it (yes?).
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
