[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
>...
> .... I don't follow argument that
> HTTP is a superfluous layer in a world of firewalls that close out most everything except
> port 80.
Firewalls exist for a reason. Ports exist for a reason. Consider the
analogous case in the real world. "When you show up at the airport, I'd
suggest you claim that you are a pilot because I've noticed that pilots
get waved through more quickly." First, it is arguably unethical, or at
least dangerous, to lie to the firewall systems put up by the guys who
are supposed to be working for the same company you do, trying to
protect it from the outside world, just like trying to "work around" the
security at the airport.
Second, security administrators *will* find a way to shut your RPC over
port 80 down, because it disgusts them, and you will have to add another
layer of obfuscation. In the long run the extra layer will be "just"
another layer. It will no longer buy you a free pass through the
firewall and you'll have to add Yet Another Layer. You end up with an
arms-war of escalating obfuscation and detection. It's like the spam or
virus detection wars except the combatants are supposed to be on the
same side!
I offer an alternative that will end the madness and stop the
escalation. Use HTTP because it is pragmatic. Also use it *as HTTP* so
that it works with, not against the firewall software and firewall
administrators. Be completely open and honest about what you are doing.
Make each message as visible as possible to the firewall. (and invisible
and opaque to hackers)
> ... In a hacker-free environment Paul Prescod would be
> absolutely right ... but what about in the world we live in?
It is precisely because we live in a hacker-full world that it makes no
sense to open up an RPC port through your firewall. Five years ago the
idea was laughable. Outside of the "web services" world it still is (not
tunnelling in general, but particularly tunnelling RPC).
> Or to put it differently, HTTP is powerful enough to be useful but limited enough to make
> it hard for hackers to attack you with.
We agree 100%. And when you run RPC over HTTP you completely blow all of
that security away.
> ... It is an inefficient use of cheap and abundant
> computer resources, but who cares, if it saves expensive and scarce human resources?
I would agree if it did. But in the end it wastes more than it was
supposed to save because now you're in an arms war with the guys who
made the firewall. You seem to think tht the arms war is with the
hackers but in fact you've made their job easier because by inventing
your own protocol you've made it MUCH harder for your sysadmins to
monitor what packets are flowing, why they are flowing, and who they are
flowing to and from. The white hats are fighting each other and making
the black hat's job easier.
Here's how I would do something:
POST /purchase_orders HTTP/1.1
Host: accounting.mycompany.com
content-type: application/purchase-order+xml
....
<po>...</po>
Here's the traditional SOAP way.
POST /generic_message_handler_where_all_inbound_crap_comes
content-type: application/SOAP+XML
<soap:envelope>
<soap:body>
<submit-purchase-order>
<destination>accounting.mycompany.com</destination>
<po>...</po>
</submit-purchase-order>
</soap:body>
<soap:envelope>
But as you know, I've left out enough namespace details to double the
size of the message. Which of the above will standard security software
help you to filter? Which of the above will a sysadmin be able to
inspect and understand in a logfile?
Using HTTP is practical. It is even more practical to read the the HTTP
spec end to end along with Fieldings writings and other writings on how
to use it properly. It sometimes takes as much work to learn to use one
tool properly than five improperly but in the long run you are better
off. That's part of the Zen of XML as much as the Zen of HTTP (or
anything else).
Paul Prescod
|
