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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, December 28, 2000 20:56
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
