[
Lists Home |
Date Index |
Thread Index
]
I don't know how to make these cases any more clearly than I did in my
essay but maybe including them textually will encourage more thought and
discussion.
1. SOAP tools encourage you to generate the network interface for your
service from the implementation of the business logic. This is
advertised as the *core Web Services feature* of Visual Studio.NET. Even
if one is deeply in love with CORBA one usually edits the IDL
implementation by hand and then generates the stub, not the other way
around. For a real, serious, public app, auto-generating your network
interface from your implementation is wrong on so many levels that I
don't even know where to begin.
2. SOAP lies. HTTP is an application protocol, not a transport protocol.
It has syntax and semantics, just as XML has syntax and semantics.
Imagine if someone asked you to submit a purchase order in some ebxml
schema and you generate a valid instance but you actually put all of the
"real" information in comments. The PO stuff is just 0's and empty
fields. And maybe you've done this because you've colluded with someone
on the "inside" to send the information this way instead of the regular
way. They told you that if you sneak it through in this way then it will
bypass the company's screening and business logic and they'll make sure
it gets approved at whatever price. This is what SOAP does to firewalls.
It lies to them. It says: "I'm HTTP traffic. I'm doing a POST. Check the
HTTP specification to know what that means." Jabber, BEEP and many other
XML protocols do not do this. They are defined at the TCP level as is
logical. Routing SOAP over HTTP is a way for someone inside the company
and someone outside the company to collude to disable the RPC-filtering
features of the service.
SOAP lies both about what it is doing (POST to do getStockQuote) but
what it is working with. "Ignore the component behind the curtain. It
isn't working with millions of resources that really should have URIs.
It's just one resource. One big fat honking resource. Really." If SOAP
ran on TCP it would not need to feel obliged to obey the rules of the
Web and HTTP. But it doesn't.
Maybe some people don't know that Schneier took on SOAP before in a
little bit more depth. He said:
"That's right. Those pesky firewalls prevent applications from sending
commands to each other, so SOAP lets vendors hide those commands as HTTP
so the firewall won't notice."
"Firewalls have good reasons for blocking protocols like DCOM coming
from untrusted sources. Protocols that sneak them through are not what's
wanted."
http://www.counterpane.com/crypto-gram-0006.html#SOAP
Roy Fielding says:
"Then what you should be doing is figuring out why HTTP makes it through
firewalls, even though firewalls predate HTTP. The theory that these
protocols will be able to get through firewalls just because they are
running on top of HTTP is just plain wrong."
"The firewalls exist to protect users. Developers advocating
generic RPC tunneling through firewalls are serving their own interests,
not
that of the users."
If I were Fielding and I carefully designed HTTP to be transparent and
thus more secure, I would be extremely annoyed to see SOAP hop on my
bandwagon. The only saving grace is that it will fail and be shut down
at the firewall again within a year.
3. SOAP is RPC.
Fielding:
"Architects use protocols to enable a defined set of communication. The
degree to which that communication is visible to intermediaries
determines
whether or not it can be safely passed through a firewall. Now what is
it about HTTP that makes it different from RPC, and thus safe for
transfer
through firewalls?"
Schneier says:
"DCOM is Microsoft's main protocol for inter-application communication.
It's not just used by programs that are intended to be servers; it's
used for all sorts of desktop communication and remote access. The
result is that an average machine has dozens of programs using DCOM.
Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to
"logagent" and including the catchily named
"{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours
by bringing up a Command Prompt and typing "dcomcnfg"."
"Now, there are lots and lots of ways to secure DCOM applications, so
maybe all of those applications are happily responding only to
authenticated requests from the local machine. On the other hand, there
are lots and lots of ways to make DCOM applications insecure, so maybe
one of them is just waiting for somebody to send it an entirely
unauthenticated request to overwrite selected files on my hard disk."
Now in two years, if Microsoft is right that SOAP is the way of the
future, how many desktop apps will you have on your machine running
SOAP? MSN Messenger, maybe Outlook, maybe a P2P app, etc.
What kind of insane system administrator would trust that the 48 SOAP
apps on your desktop are secure enough to allow access from outside the
firewall? What he's going to do?
Because SOAP is *so generic* it is essentially impossible to understand
what is going on by knowing merely that there are SOAP packets flowing
across the network. SOAP has none of the application semantics of HTTP
which allow one to know, for instance, that barring tunnelling or a bug,
a GET coming from the outside in is safe.
Note that I said barring tunnelling. Once we agree that what SOAP does
is legit we've opened the door to tunnelling and thenceforth, all bets
are off. Maybe GET sometimes means POST in the future. Maybe PUT means
GET. The precedent has been set. Any corporation in its right mind would
have a strong policy against tunnelling and SOAP is tunnelling.
Both Fielding and Schneier make a point about the *generality* of RPC
protocols. And Fielding also makes a point about the opacity of RPC
protocols. And both make the point about tunnelling, which is a form of
fraud. (by the way, I'm in favour of tunnelling in some
circumstances...but I know it is an intrinsic blow against security).
So to say it "isn't RPC versus REST" is to miss the point. These two
people who know ten times more than I do about protocols and security
both claim it is *entirely about RPC*.
Paul Prescod
|
