[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
>
> OK. I see your point. But I would still say a couple of things about this.
>
> Making it "easy" to get through the firewall is not the same as
> "subversion". The SOAP spec even offers a header explicitly for filtering at
> the protocol layer: the SOAPAction header.
If you don't want to subvert the firewall then there is a very easy way
to do otherwise. You choose a new port and fight your way through the
firewall as HTTP did and Jabber has not yet. That's the way the Internet
works. Why does SOAP get to change the rules?
Why do we have port numbers if henceforth everything is going to go
through port 80. Is that logical?
SOAPAction would be better than nothing but it was poorly described to
start with and is now optional:
"Use of the SOAP Action feature is OPTIONAL. SOAP Receivers MAY use it
as a hint to optimise processing, but SHOULD NOT require its presence in
order to operate. Support for SOAPAction is OPTIONAL in implementations.
Implementations SHOULD NOT generate or require SOAPAction UNLESS they
have a particular purpose for doing so (e.g., a SOAP Receivers specifies
its use)."
I understand that in practice,
> use of this header is rather uneven. But it seems to have been an explicit
> attempt by the spec writers to provide visibility to the firewall, among
> other things. I'd be interested in your opinion on this. Would it help if
> implementations treated the SOAPAction header more seriously, or was that
> proposal a misfire to begin with?
SOAPAction was a good idea with poor implementation. But let's go back
to my purchase order example. If I started tunnelling purchase orders
through comments in otherwise meaningless documents would you be happy
if I added a <?po-hack ?> processing instruction?
> The fact that tools by certain vendors promote questionable approaches is
> not the same as the standard itself being flawed. Rather than fixating on
> Microsoft's tools, I'd rather hear analysis focusing on the spec itself.
I think that spec itself has three security weaknesses (holes would be
too strong of a word). One is that it is designed to tunnel through HTTP
rather than using its own port as is standard on the Internet. Two is
that it leaves more in the realm of the application developer than needs
to be left. They must invent their own addressing model. They must
invent their own methods. This raises the bar for the security knowledge
they need. Three it is RPC which makes it difficult for sysadmins to
filter and monitor because it is too general and opaque. I can't make
that last point too strongly and I'll point (again) to the writings of
Fielding and Schneier. I'll try a different URI this time:
"What makes HTTP significantly different from RPC is that the requests
are directed to resources using a generic interface with standard
semantics that can be interpreted by **intermediaries** almost as well
as by the machines that originate services." **intermediaries** in this
case are firewalls."
"Most of the recently proposed extensions to HTTP, aside from WebDAV
[60], have merely used HTTP as a way to move other application protocols
through a firewall, which is a fundamentally misguided idea. Not only
does it defeat the purpose of having a firewall, but it won't work for
the long term because firewall vendors will simply have to perform
additional protocol filtering. It therefore makes no sense to do those
extensions on top of HTTP, since the only thing HTTP accomplishes in
that situation is to add overhead from a legacy syntax."
*
http://www1.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3
=====
BTW, in the last few weeks of argument here I'm yet to hear an inspired
argument in favor of SOAP. Anyone here think it's great? Really
inspired? Wonderful?
That's kind of interesting to me. If SOAP had been invented by a couple
of smart programmers and published as a spec, what kind of user pull
would there be for it?
Paul Prescod
|
