Posted by
Hemos
on from the programming-with-dial dept.
Irish writes "This IBM developerWorks article discusses the theoretical underpinnings of SOAP's type system. Its a good article for anyone who wants to learn more about SOAP's programmatic support or to simply better understand Apache's SOAP."
SOAP's popularity will be its problem
by
conan_albrecht
·
· Score: 5, Insightful
I just wrote an article on this. SOAP gets past firewalls because it *looks* like web traffic (at least, HTTP traffic). That's great because most firewalls let HTTP traffic on port 80 through.
However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
One of the reasons that RMI and CORBA are firewalled is because they provide remote access to *objects* that might be powerful and that can certainly execute behavior within the trusted environment. SOAP does exactly the same thing, only it looks like HTTP traffic.
Yes, SOAP can be detected very easily by firewalls. Therefore, I'm predicting that as it becomes popular, many admins won't let it through as easily as it gets through today.
My $0.02.
Re:SOAP's popularity will be its problem
by
pauljlucas
·
· Score: 2, Insightful
However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
But if they get in via port 80, then your servers are the ones providing the services because you told them to. This isn't very much different from a non-SOAP GET/POST request and a response.
-- If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
You certainly can preach about 'feature-above-security mindset that needs to go' for as long as you want, but when it will come to the product not working at your biggest customer site due to the firewall setup and them not willing to mess it up just for trying out yet-another-beta proggy, you will consider SOAP, stunnel, httptunnel and anything else that will get you closer to the goal.
I agree that positioning SOAP as firewall-transparent protocol is.. err.. may get interpreted incorrectly by less experienced members of comp.sci society, but.. hey!.. you can misuse almost everything.
.. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break... Once you start tuning the performance, you realize that bottleneck is often exactly in the freaking SOAP layer with its bloated XML data encoding. You certianly can compress it, but what's the need in XML there for then ?
-- 3.243F6A8885A308D313
Re:Redundant Post xml-rpc is by far better
by
pauljlucas
·
· Score: 2, Insightful
Let's see 2 page spec vs 200, come on people wake up!
Bloated, over-engineered specs are typical of the W3C because the committees are often dominated by the big players (Microsoft, Oracle, Sun, etc.) and it's in their best interest to make standards so big and complex that only companies having their scale of resources will be able to produce compliant implementations thus shutting out the little players.
-- If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Re:Bruce Schneier has said:
by
microTodd
·
· Score: 4, Insightful
If you use SSL with either Basic Authentication or some PKI mechanism then you could somewhat trust your client anyways.
Also, some SOAP/Servlet containers don't run on port 80, they run on port 8080 or something like that. Just because it uses HTTP doesn't mean its using port 80.
Besides, shouldn't your public web server be in the DMZ anyways, and your SOAP application server inside the firewall? So why are you allowing all port 80 traffic inbound?
-- "You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
Corba over HTTP(S)?
by
Baki
·
· Score: 4, Insightful
One of the advantages of Soap is proclaimed to be that it runs over HTTP (available everywhere) and also it is buzz-work compliant (XML).
One could also run Corba over HTTP. Corba can use any transport medium. IIOP was only intended to be one of many possible, and if firewalls etc are really the problem, then why not run Corba over HTTP?
I don't see any other 'advantages' from Soap over Corba. WSDL is an XML format describing the service. Why should it be better than IDL? Both can be parsed by machines and read by humans. With DII (dynamic invocation interface) one can build in generic Corba-over-HTTP client functionality in any program (such as a webbrowser).
Really, what's new? What's wrong with Corba? Implementing a Corba service in a language such as Java (which takes care of memory management issues and integrates very well with IDL) is trivial. Writing clients even more so.
They should include an additional escape mechanism to solve this problem directly, like (to borrow the horrid CDATA syntax):
<![BDATA[10 xxxxxxxxxx]]>
where the "BDATA" means "Binary Data", and the "10" is the number of binary bytes in ascii decimal followed by a single space followed by the indicated number of bytes of raw binary.
Honestly, what kind of rabid theoreticians designed XML anyway and didn't include a mechanism for raw binary? Were they thinking that people would encode images like:
Of course, with XML you also face an enormous lexical-scanning cost. One can easily derive a fully-interoperable totally-equivalent binary encoding for XML; perhaps one day people will realize that it's not efficient to pass everything around in text. Imagine spending all day parsing a big array of real numbers encoded in text rather than slurp/swapping raw 8-byte IEEE doubles.
Re:Bruce Schneier has said:
by
Zeinfeld
·
· Score: 4, Insightful
Bruce says many things he really should not and often with far less thought than he should. You would think that someone who spends so much time talking to journalists would understand the way his pronouncements are taken.
The reason that Bruce is quoted so often on security is that he returns journalists calls within an hour or two and gives a quotable quote by the deadline.
I discussed the SOAP paper with Bruce and Adam. The comment about SOAP was not intended to be taken as gospel, it was simply a throw-away comment added to the end of a section.
Bruce's security expertise is largely in the area of cryptography. He has not been a player in the network security protocols area. His last foray into that area was his criticism of IPSEC which was wrong on almost every count according to Steve Bellovin (who knows rather a lot about internet firewalls having helped invent them)
The criticisms Bruce makes would be valid if they had not been anticipated. Microsoft has actually developed a very comprehensive security architecture for SOAP and.NET, one of the lead designers was Brian LaMachia who some folk will know as the one time author of the MIT PGP key server.
A big problem with firewalls is that they are in most cases managed by people whose job is to stop bad things happening, it is not their job to help make usefull things happen.
Another big problem is that they are often used in the manner of a +5 amulet of protection against hackers, the company does not know how they work but they hope they will ward of attacks. My company installs and configures firewalls. It is not uncommon for our PSO to go onsite to re-configure a longstanding installation and find that it is configured for passthrough on all ports.
If you deploy SOAP you need an application layer firewall. Which coincidentally Microsoft just happened to demonstrate at RSA 2002. Now running a firewall on top of Win2K would be a pretty bad idea, you don't want a full feature O/S for that type of application. But running a firewall over the NT for embedded systems that is comming soon would be a pretty good idea, particularly with the.NET security framework.
--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation.
This doesn't make a lot of sense to me. How can software automatically "understand" an interface? Claiming that some declarative language can define the semantics of an interface seems equivalent to claiming to be able to solve the halting problem. And without understanding semantics, how can an application make effective use of any non-trivial interface? The notion of "self-describing" interfaces sounds a lot like fantasy. Any actual intelligence must be pre-programmed into the application, according to some pre-published human-understandable specification.
Lots of XML fanboys also like to wank off about validation, but outside of debugging, what is really the point? It's a low-utility activity. Syntax != Semantics, and a syntactic description is all that whiz-bang gives you.
Slashdot Mirror
I just wrote an article on this. SOAP gets past firewalls because it *looks* like web traffic (at least, HTTP traffic). That's great because most firewalls let HTTP traffic on port 80 through.
However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
One of the reasons that RMI and CORBA are firewalled is because they provide remote access to *objects* that might be powerful and that can certainly execute behavior within the trusted environment. SOAP does exactly the same thing, only it looks like HTTP traffic.
Yes, SOAP can be detected very easily by firewalls. Therefore, I'm predicting that as it becomes popular, many admins won't let it through as easily as it gets through today.
My $0.02.
You certainly can preach about 'feature-above-security mindset that needs to go' for as long as you want, but when it will come to the product not working at your biggest customer site due to the firewall setup and them not willing to mess it up just for trying out yet-another-beta proggy, you will consider SOAP, stunnel, httptunnel and anything else that will get you closer to the goal.
.. err .. may get interpreted incorrectly by less experienced members of comp.sci society, but .. hey! .. you can misuse almost everything.
... Once you start tuning the performance, you realize that bottleneck is often exactly in the freaking SOAP layer with its bloated XML data encoding. You certianly can compress it, but what's the need in XML there for then ?
I agree that positioning SOAP as firewall-transparent protocol is
.. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break
3.243F6A8885A308D313
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
If you use SSL with either Basic Authentication or some PKI mechanism then you could somewhat trust your client anyways.
Also, some SOAP/Servlet containers don't run on port 80, they run on port 8080 or something like that. Just because it uses HTTP doesn't mean its using port 80.
Besides, shouldn't your public web server be in the DMZ anyways, and your SOAP application server inside the firewall? So why are you allowing all port 80 traffic inbound?
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
One of the advantages of Soap is proclaimed to be that it runs over HTTP (available everywhere) and also it is buzz-work compliant (XML).
One could also run Corba over HTTP. Corba can use any transport medium. IIOP was only intended to be one of many possible, and if firewalls etc are really the problem, then why not run Corba over HTTP?
I don't see any other 'advantages' from Soap over Corba. WSDL is an XML format describing the service. Why should it be better than IDL? Both can be parsed by machines and read by humans. With DII (dynamic invocation interface) one can build in generic Corba-over-HTTP client functionality in any program (such as a webbrowser).
Really, what's new? What's wrong with Corba? Implementing a Corba service in a language such as Java (which takes care of memory management issues and integrates very well with IDL) is trivial. Writing clients even more so.
<![CDATA[ BINARY DATA HERE BASE 64 ENCODED ]>
...
They should include an additional escape mechanism to solve this problem directly, like (to borrow the horrid CDATA syntax):
<![BDATA[10 xxxxxxxxxx]]>
where the "BDATA" means "Binary Data", and the "10" is the number of binary bytes in ascii decimal followed by a single space followed by the indicated number of bytes of raw binary.
Honestly, what kind of rabid theoreticians designed XML anyway and didn't include a mechanism for raw binary? Were they thinking that people would encode images like:
<img:image>
<img:row>
<img:pixel>
<img:red>0xFF</img:red>
<img:green>0xFF</img:green>
<img:blue>0xFF</img:blue>
<img:opacity>0xFF</img:opacity>
</img:pixel>
</img:row>
</img:image>
Of course, with XML you also face an enormous lexical-scanning cost. One can easily derive a fully-interoperable totally-equivalent binary encoding for XML; perhaps one day people will realize that it's not efficient to pass everything around in text. Imagine spending all day parsing a big array of real numbers encoded in text rather than slurp/swapping raw 8-byte IEEE doubles.
The reason that Bruce is quoted so often on security is that he returns journalists calls within an hour or two and gives a quotable quote by the deadline.
I discussed the SOAP paper with Bruce and Adam. The comment about SOAP was not intended to be taken as gospel, it was simply a throw-away comment added to the end of a section.
Bruce's security expertise is largely in the area of cryptography. He has not been a player in the network security protocols area. His last foray into that area was his criticism of IPSEC which was wrong on almost every count according to Steve Bellovin (who knows rather a lot about internet firewalls having helped invent them)
The criticisms Bruce makes would be valid if they had not been anticipated. Microsoft has actually developed a very comprehensive security architecture for SOAP and .NET, one of the lead designers was Brian LaMachia who some folk will know as the one time author of the MIT PGP key server.
A big problem with firewalls is that they are in most cases managed by people whose job is to stop bad things happening, it is not their job to help make usefull things happen.
Another big problem is that they are often used in the manner of a +5 amulet of protection against hackers, the company does not know how they work but they hope they will ward of attacks. My company installs and configures firewalls. It is not uncommon for our PSO to go onsite to re-configure a longstanding installation and find that it is configured for passthrough on all ports.
If you deploy SOAP you need an application layer firewall. Which coincidentally Microsoft just happened to demonstrate at RSA 2002. Now running a firewall on top of Win2K would be a pretty bad idea, you don't want a full feature O/S for that type of application. But running a firewall over the NT for embedded systems that is comming soon would be a pretty good idea, particularly with the .NET security framework.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation.
This doesn't make a lot of sense to me. How can software automatically "understand" an interface? Claiming that some declarative language can define the semantics of an interface seems equivalent to claiming to be able to solve the halting problem. And without understanding semantics, how can an application make effective use of any non-trivial interface? The notion of "self-describing" interfaces sounds a lot like fantasy. Any actual intelligence must be pre-programmed into the application, according to some pre-published human-understandable specification.
Lots of XML fanboys also like to wank off about validation, but outside of debugging, what is really the point? It's a low-utility activity. Syntax != Semantics, and a syntactic description is all that whiz-bang gives you.