Via Sam Ruby's blog post entitled Equal Time I noticed that there has been an interesting conversation brewing about message security and RESTful Web services between Pete Lacey and Gunnar Peterson. However they both seem to be cherry picking parts of each others arguments to dispute which reduces some the educational value of their posts.
Gunnar Peterson started the discussion going with his post
REST Security (or lack thereof) where he writes
So the whole REST security thing just gets funnier, the S for Simple folks forget that S also stands for security. Here was a response
to my post on the fact that people who say REST is simpler than SOAP
with WS-Security conveniently ignore things like, oh message level
security:
HTTP Basic or HTTP Digest or SSL (certificate-based) for
authentication. SSL for encryption and digital signatures. You know,
the way we've been doing things since 1995.
Where to start? Right, it was state of the art in 1995. no bout a
doubt it. The world has moved on slightly since then. You know a couple
97 million stolen identities, endless phishing/pharming (growing double digit pct each month), malware taking 60% cpu utilization on consumer desktops. You know little stuff like that
...
Now if you are at all serious about putting some security mechanisms in to your REST there are some good examples. One being Amazon's developer tokens
using HMAC for authentication at the message level (you know where the
data is). But if you are going to say that REST is so much simpler than
SOAP then you should compare REST with HMAC, et. al. to the sorts of
encryption and signature services WS-Security gives you and then see
how much simpler is. And, you know, maybe even see, oh golly gee I
don't know, which one protects your customers' data better? Until then,
we'll just continue (as Gene Spafford said) using an armored car to deliver between someone living in a cardboard box and someone living on a park bench.
Gunnar has a good point which he ruins with some of his examples. The point being that HTTP authentication and SSL aren't the be all and end all of securely communicating on the Web. However his examples of spyware and phishing are unrelated to his point and end up harming his argument. For one, there's nothing one can do at the service security layer to protect against a user that has malware running on their computer. Once the user's machine has been compromised, it is over. As for phishing, that is a problem that relies on the unique combination of social engineering and the unfortunate characteristics of email readers and Web browsers. Phishing is not really an architectural problem that affects machine to machine interaction via Web service. It is an end user problem of the HTML Web.
In Pete Lacey's response entitled RESTful Security he writes
Gunnar notes that the world has moved past SSL etc., and cites as
examples identity theft, phishing/pharming, and malware. But these
security threats are completely orhtogonal to the security concerns SSL
addresses. Ditto, I might add, WS-Security. Both of these standards
address identity propagation, message encryption, and message integrity
only, and neither will protect you from the threats just mentioned.
Security is a BIG subject and the areas covered by SSL and WS-Security
are just one small part of it. We also need good practices around
securing persisted data (and what data to persist); education to
prevent social engineering attacks; properly designed operating systems
that won’t run anything with a .exe extension or run needless services;
developers who are cognizant of buffer overflows, SQL injection, and
cross-site scripting attacks; properly managed perimeter defenses; and
so on and so on.
...
With all of that behind us, I can get on to what seems to be
Gunnar’s main point and the only significant difference (outside of the
whole simplicity and interoperability thing) between SSL and
WS-Security. And that is that SSL provides transport level,
point-to-point security while WSS provides message level, end-to-end
security. That’s true, but that doesn’t provide WSS with magical
security powers, it just solves a different problem. Nor does it
relegate SSL to the scrap heap of history. SSL is not a security
panacea–nothing is, but it does what it is does very well. Regardless,
there is nothing in REST that prohibits the use of message-level
encryption, though the mechanism–should it be needed–would need to be
spec’d out.
I’m not dismissing WSS, it’s a perfectly adequate specification for
what it does (though it requires the WS-I Security Profile to introduce
enough constraints to provide a reasonable chance of interoperability).
But the value of message level security should still be questioned. For
one thing, what’s the business case? If message-level encryption is so
important, why isn’t anyone using it? When Burton Group queried its
clients as to their use of WSS, it was found that the only use was to
pass identity tokens over HTTPS. When I was working at Systinet (now HP) I vividly recall the WASP
(not Systinet Server for Java) product manager spitting nails because
his team had just spent six months implementing WSS at our customer’s
request and no one–not even those who requested the feature–was using
it. Also, this is not the first time message level security has been
proposed. When I was working at Netscape back in 1997 I spent a fair
amount of my time advocating for S/MIME. Now, nearly ten years later, how many people are using S/MIME to secure their email? And how many are using SSL? Exactly.
I tend to agree with Pete Lacey that a lot of the people who claim that they need message level security actually are fine with the transport level security provided by SSL. Message level security is primarily needed if the message will be passing through hostile intermediaries without secure point-to-point communications between the sender and receiver. But how often does that really happen on the Web? One could argue that the vaunted example by Gunnar Peterson, Amazon Web Services which utilize HMAC-SHA1 hashes of a developer's secret key for authentication could just as easily have been implemented using SSL. After all, man-in-the-middle attacks are prevented in both examples. If the issue is what happens if the sender's machine has been compromised (e.g. by malware) then both approaches fall down flat.
That said, there are times when one has to author an application where the message has to pass through potentially hostile intermediaries and message level security is needed. I've actually had to deal with one such situation in my day job so I know that they are real although I doubt that there are many that will encounter the exact same problem that we did at work.
Once you get to that point, the tough problems are usually around key exchange, key protection and key revokation not around the niceties of whether you should roll your own usage of XML Signatures or should go with a fully featured yet inconsistently implemented protocol like WS-Security. Using the Amazon Web Services as an example, I couldn't find any information on how to protect my secret key beyond admonitions "not to send it around in email" nor did I find any mechanism to revoke or reissue my secret key if it became compromised. As a Web service developer, you'll likely spend more time worrying about those issues than you will figuring out how to integrate signing or encryption of XML documents into your RESTful Web Service.