OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: RE: "new" protocols vs. firewalls & firewall adminis{trators|tration} ?
From: Bill Royds (broydshome.com)
Date: Thu Dec 28 2000 - 22:40:15 CST

The real problem is the many attempts to bypass security by tunnelling other protocols over HTTP.
If a protocol has a well defined syntax and semantics that allow full control by the client of an activity in the protocol, then there is little risk of using it over a well-defined TCP port.
If I can write a proxy program for the protocol that can guarantee that all transactions using the protocol act in a secure well defined manner, then using a standard TCP or UDP well-known port is much more efficient and easier than trying to embed it in HTTP.
   What seems to be the problem is the desire to allow server driven transactions over a protocol that is universally enabled in order to bypass considerations of security and integrity. What SOAP will do is destroy the trust model of HTTP (all actions are initiated by the client) so that one can no longer trust HTTP as a fairly secure protocol. If distributed computing is required, then one needs to establish a proper trust model for this (signed applications, capability architectures etc.) before deploying an un-trusted insecure architecture all over the Internet.

-----Original Message-----
From: firewalls-ownerLists.GNAC.NET
[mailto:firewalls-ownerLists.GNAC.NET]On Behalf Of
Jeff.Hodgeskingsmountain.com
Sent: Thursday, December 28, 2000 20:56
To: firewallsLists.GNAC.NET
Cc: Jeff.Hodgeskingsmountain.com
Subject: "new" protocols vs. firewalls & firewall
adminis{trators|tration} ?

Some emerging new protocols, notably SOAP (http://www.w3.org/TR/SOAP/) are
explicitly layered on top of HTTP. A prominently cited reason for this goes
something like..

  Firewalls usually have port 80 (HTTP) enabled (one way or another), and
  "most firewalls block non-HTTP requests" [1], so if we layer our new protocol
  abstraction on top of HTTP, we can deploy applications using said protocol
  and they will just work.

..with the implication being that such apps will "just work without my having
to {ask|convince|conjole|coerce} my firewall admin to open new/additional
ports on our firewall.

So, I'm curious -- what do the firewall admin types on this list think about
this?

A subtle-but-important point is that as described in [1], the DCOM protocol,
and ones like it (e.g. DCE-based protocols), dynamically use a range of ports,
and ~this~ is apparently a big part of the perception that firewall admins are
reluctant to provide for passage of such protocols across their firewalls.

But, what if a new protocol is cleanly specified on a IANA-assigned well-known
port (e.g. like LDAP is) -- then is it an issue to the firewall admins to
incorporate it into their configurations? I.e. if I'm an app-deployer at Foo
Corp, and I purchase some nifty new stuff that needs to be accessible across
various security perimeters (defined at least in part by firewalls), and uses
some new protocol that's legitimately assigned to a well-known port, then is
this a Big Deal (tm) that I should expect my company's security administrators
to have a cow over or not? How might the scale and/or purpose of the company's
network affect this?

Also, there's various discussions of the security considerations involved in
running effectively new protocols on top of other application-layer protocols
(read: HTTP, but not limited to it) in [2] and [3]. What do you firewall admin
types think of the arguments presented therein?

thanks,

JeffH

[1] SOAP: The Simple Object Access Protocol, Aaron Skonnard
    http://msdn.microsoft.com/library/periodic/period00/soap.htm

[2] SOAP, Bruce Schneier
    http://www.counterpane.com/crypto-gram-0006.html#SOAP

[3] On the use of HTTP as a Substrate for Other Protocols
    http://www.ietf.org/internet-drafts/draft-moore-using-http-01.txt

-
[To unsubscribe, send mail to majordomolists.gnac.net with
"unsubscribe firewalls" in the body of the message.]