Skip to content

RESTful Security

Over in the comments for Tim Bray’s “S for Simple” post and again over on his personal blog, Gunnar Peterson claims that the standard REST security approach is inadequate and that something like WS-Security is required for any truly secure architecture. Gunnar has a shoot-from-the-hip tone, but we’ve communicated briefly via email and he states that he would like to buy into the REST vision if only security was adequately addressed. So lets compare and contrast approaches.

The standard RESTful security approach is, of course, HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials (the actual act of authentication and authorization being the purview of the server) and SSL for data integrity (digital signatures) and data protection (encryption). Gunnar notes that these technologies were state of the art in 1995, with the implication they are no longer sufficient for meeting the security needs of the 21st century. This is an example of what I call the “Gilligan, you can’t fly” argument; that is stating that something can’t be done even as somebody else is doing it. The fact is that billions of dollars of worth of business is conducted every year over because of SSL.

SSL has shown itself to be amazingly versatile. Not only do I do my online banking and shopping over SSL, I VPN into the office over SSL and check and send email over SSL. That the first version of SSL is now some 11 years old is a boon. In fact, that’s exactly what I want in a standard; stability for the long term. More so in a security related standard, as that provides the time to shake out any bugs and ambiguities. Of course, SSL hasn’t been static; there’s been SSL 2, and SSL 3, and now TLS 1.1. In fact, given the relative youth of WS-Security, what do you think the odds are that it is immune to attack and that all of the implementations are free from bugs? Close to zero I would imagine. That’s not a slam on WSS–all standards are young once–but praise for the tried and true.

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.

Gunnar then notes that HTTP Basic is not secure, and that, of course, is absolutely true. The password passed via HTTP Basic is base64 encoded, which is practically the same thing as being sent in clear text. In fact, it is the same thing, as encoding is not encryption. However, nobody is claiming otherwise. For those use cases where identity is all that’s required, then HTTP Basic is all that’s needed. For the larger number of use cases where credentials need to be encrypted, then use HTTP Basic in conjunction with SSL or use HTTP Digest or use SSL mutual auth. I’ll note that WSS is similar in design. The standard identity token is the Username token, the password element of which is sent in the clear by default. You can hash the password, but it should be noted that the recommendations specified in the Username Token Profile require that the server store the user’s password in clear text. Avoiding this requires an out-of-band negotiation that cannot be specified using WS-SecurityPolicy.

Gunnar next takes SSL to task for providing a great big hole through the firewall. I have to confess that I don’t understand this point. Sure, SSL encrypts the content of the communication channel, but that’s what it’s supposed to do, and, as already noted, it seems to work pretty well. Furthermore, when using HTTPS, communication travels through a completely different port than HTTP. A port that can be monitored more carefully. With WSS, not only do we have SOAP tunneling over HTTP, we have encrypted messages in the SOAP envelope. I don’t see how that could be better. In fact, the SOAP tunneling alone is a fairly significant security hole. Requiring that companies invest in new infrastructure to secure against threats that bypasses all the stuff they’ve already deployed. Furthermore, it’s not like the SSL connection is being terminated on the application server, more likely than not there is some intermediary up front that terminates the session, e.g. an SSL accelerator or proxy server. And before you can say, “ah hah,” know that the same is true for WSS. A properly architected SOA security solution addresses security concerns in “the cloud” using either an XML gateway or a web services management solution. (An article I wrote on this subject goes into more detail.) In other words, done right, the message received by a WSS-secured endpoint is also in the clear.

Gunnar goes on to note that the point-to-point security offered by SSL is an interoperability and simplicity nightmare. I don’t get this point either. Not only is SSL well understood, broadly implemented, and properly constrained, it is quite evidently not an impediment to interoperability as I can securely connect to anyone on the planet right now, so long as they let me. In contrast, not only is SOAP well known for its continuing interoperability headaches, they show up in spades with WSS. Just for starters, how do I know that a SOAP endpoint is secured in any way? You can’t tell from the URL and there’s no handshake with which client and server can negotiate security. If a service is secure, in what way? Do I need to provide credentials? What kind? A Username token? (hashed?) A SAML token? (how much of SAML do you support?) Or an encoded certificate? Is encryption used? The whole message or just some elements? Do I need to sign it? You can say that all of this is addressed by WS-SecurityPolicy, but WS-SecurityPolicy isn’t baked yet nor is anyone using it. And, as we’ve just shown, it’s not comprehensive. Furthermore, we have the implementation details. Is, say, BEA’s WSS implementation really 100% compatible with Microsoft’s, and is that 100% compatible with IBM’s, and is that 100% compatible with AmberPoint’s, and so on down the line. I don’t know the answer to this (since there doesn’t seem to be any instances of WSS encryption/DSig use in the wild [read the comments too]), but I strongly suspect not. To demonstrate, please retrieve this encrypted representation of a common greeting. Now, I don’t know what browser you’re using (if any) or what OS or anything. And you don’t know what encryption algorithm I’m using or what version of SSL etc. However, even though we have no a priori information about each other, I am absolutely positive that you were able to retrieve that resource. What can be simpler than that?

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.

In summary, RESTful security, that is SSL and HTTP Basic/Digest, provides a stable and mature solution that addresses transport level credential passing, encryption, and integrity. It is ubiquitous, simple, and interoperable. It requires no out-of-band contract negotiation or a priori knowledge of how the resource (okay, service) is secured. It leverages your existing security infrastructure and expertise. And it addresses 99% of the use cases you are likely to encounter. SSL does not support message level security, and if that’s a requirement, then leveraging SOAP and WSS makes sense. Recall, though, that this is not a limitation of REST per se, though it is left as an exercise to the reader. SSL is not perfect and it does not address all security requirements, but nothing does or can.

Hope that helps.

{ 19 } Comments

  1. Gunnar | December 2, 2006 at 12:48 am | Permalink

    I really can’t say it any better than Don Smith already did

    “The message is king … and the contract is queen”

  2. Stephan Fowler | December 3, 2006 at 3:45 pm | Permalink

    FYI, take a look at httpsec.org for a HTTP message authentication scheme using strong crypto.

  3. Wes Jackson | June 25, 2009 at 10:38 am | Permalink

    Pete Lacey is a genius!

  4. carlos | July 26, 2010 at 12:49 pm | Permalink

    throw this shit away and use SOAP!

  5. Lean Grava | June 14, 2011 at 8:55 am | Permalink

    Thanks to this engineering, our job where able to research a life threatening fraudulence. His is a most have in every company. CCTV Camera

  6. alfred angelo | May 8, 2013 at 2:15 pm | Permalink

    I believe everything said made a lot of sense. But, what about
    this? suppose you composed a catchier post title?
    I mean, I don’t wish to tell you how to run your website, but suppose you added a title that makes people desire more? I mean Pete Lacey?s Weblog : RESTful Security is a little vanilla. You might look at Yahoo’s home
    page and see how they create article headlines to get people
    to click. You might add a video or a picture or two
    to grab readers interested about what you’ve written. In my opinion, it would make your posts a little bit more interesting.

  7. home based | May 21, 2013 at 3:25 pm | Permalink

    Woah! I’m really loving the template/theme of this blog. It’s simple, yet
    effective. A lot of times it’s difficult to get that “perfect balance” between user friendliness and appearance. I must say you’ve done
    a amazing job with this. Also, the blog loads extremely quick for me
    on Opera. Superb Blog!

  8. www. | May 23, 2013 at 1:58 pm | Permalink

    Fantastic goods from you, man. I have understand your stuff previous to and you’re just extremely great. I really like what you’ve acquired here,
    really like what you’re saying and the way in which you say it. You make it enjoyable and you still care for to keep it smart. I can’t wait to
    read far more from you. This is really a terrific web site.

  9. hersolution | June 2, 2013 at 9:43 am | Permalink

    This is really interesting, You are a very skilled
    blogger. I have joined your feed and look forward to seeking more of your magnificent post.
    Also, I’ve shared your website in my social networks!

  10. buy wartrol | June 6, 2013 at 4:58 am | Permalink

    It’s in reality a great and useful piece of information. I am happy that you shared this helpful info with us. Please keep us up to date like this. Thanks for sharing.

  11. forum-spk.com.ua | June 11, 2013 at 11:54 am | Permalink

    Heya! This is the second time visiting now and I just wanted to say I
    truley fancy reading your blog. I decided to bookmark it at delicious.
    com with your title: Pete Lacey?s Weblog : RESTful Security and your URL:
    http://wanderingbarque.com/nonintersecting/2006/12/01/restful-security/.
    I hope this is okay with you, I’m making an attempt to give your terrific blog a bit more coverage. Be back shortly.

  12. replicamiumiuhandbag | June 21, 2013 at 8:52 pm | Permalink

    It an awesome paragraph Pete Lacey’s Weblog : RESTful Security designed for all the internet viewers; they will get advantage from it I am sure. replica miu miu handbag http://www.voguebagsstore.com/miu-miu-handbags-c-7.html

  13. Stephany | June 26, 2013 at 2:20 am | Permalink

    Does your website have a contact page? I’m having trouble locating it but, I’d like to shoot you an email.
    I’ve got some ideas for your blog you might be interested in hearing. Either way, great site and I look forward to seeing it expand over time.

  14. http:// | July 18, 2013 at 1:25 am | Permalink

    I’ve been exploring for a little bit for any high-quality articles or blog posts on this sort of house . Exploring in Yahoo I ultimately stumbled upon this web site. Studying this info So i’m glad to convey that I have
    an incredibly excellent uncanny feeling I discovered just what I needed.
    I such a lot indubitably will make sure to do not forget this site and provides it a look on a continuing basis.

  15. http:// | November 18, 2013 at 9:13 pm | Permalink

    The app lets you post on multiple platforms at once, which
    saves you considerable time if you use images in your social media marketing.
    With the popularity of this application, like purchasing followers for
    facebook, Twitter, Linked - In and similar social networking sites, people also showing interest to buy instagram followers and to
    help out these people, many organizations are offering this
    service. This includes the ability to add more carts, popularity, menus and more.

  16. http://www. | December 2, 2013 at 8:28 pm | Permalink

    What’s up colleagues, good post and good urging commented here, I am truly enjoying by these.

  17. Shanghai Resorts | December 11, 2013 at 3:31 pm | Permalink

    excellent i?xsues altogether, you simply won a new ?eader.
    What would you ?ecommend about your submit that you made a few ?ays in thhe past?
    Any certain?

  18. 641 Economy Cal | February 26, 2014 at 9:09 am | Permalink

    It is easy, but ensuring you get a stronger hold over the way stocks and the
    markets are here to stay and so markets 1st saturday victoria is St.

  19. VPS | April 1, 2014 at 3:01 am | Permalink

    As the admin of this web page is working, no uncertainty
    very soon it will be famous, due to its feature contents.

{ 9 } Trackbacks

  1. franklinmint.fm | December 2, 2006 at 12:23 am | Permalink

    More On HTTP Security…

    Pete Lacey has a post on RESTful Security. When I read posts like that, I often wonder how the following……

  2. Stefan Tilkov's Random Stuff | December 2, 2006 at 3:56 am | Permalink

    REST Security…

    Pete Lacey responds to Gunnar Peterson’s claims about REST’s lack of message level security. I find it awfully hard to add anything to that, so go read the original post…….

  3. [...] I trust the water piped directly to my house, but I more careful when it comes to packages which flop through my letterbox. A signed-sealed envelope delivered by a courier boosts my confidence, but helps a lot if I know who sent it. So whilst WS-Security offers a little more than just TLS, it’s the thought and effort being expended to establish and exchange identity that currently gives WS-* the security edge over REST. It’s great to see that RESTians are starting to at least see the issue, triggered by Pete Lacy and Gunnar Peterson’s great posts. But don’t panic: I suspect the establishment of Trust and exchange of Identities may indeed be answered by SOAP/WSS, only it’ll be baked-hard and packaged into something like the CardSpace stack. That way the slippy stuff won’t prevent us from continuing to use the Web and getting shit done. [...]

  4. [...] RESTful Security (tags: authentication rest security soapm SSL ws-security by:pete_lacey HTTP) [...]

  5. [...] The REST vs WS wars continue. Pete Lacey has an insightful post on RESTful Security [...]

  6. Dare Obasanjo aka Carnage4Life | December 6, 2006 at 8:28 pm | Permalink

    REST and Message Security…

  7. marten.gustafson » links for 2006-12-13 | December 13, 2006 at 5:17 pm | Permalink

    [...] RESTful Security (tags: http messaging rest security by:pete_lacey ws-security ssl) [...]

  8. Mark O'Neill's Radio Weblog | February 4, 2007 at 1:33 pm | Permalink

    REST and SOAP…

  9. [...] Pete Lacey lays out the counterpoint, saying that SSL works just fine for tons and tons of use cases, thankyouverymuch. In summary, RESTful security, that is SSL and HTTP Basic/Digest, provides a stable and mature solution that addresses transport level credential passing, encryption, and integrity. It is ubiquitous, simple, and interoperable. It requires no out-of-band contract negotiation or a priori knowledge of how the resource (okay, service) is secured. It leverages your existing security infrastructure and expertise. And it addresses 99% of the use cases you are likely to encounter. SSL does not support message level security, and if that’s a requirement, then leveraging SOAP and WSS makes sense. [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *