WS-Security vs. SSL

A blog post by Doug Reilly brought to mind discussions that I had with some service architects earlier in the year.  The question was whether it was better to use SSL or WS-Security to secure SOAP messages as they travel from the client to the server and back again.  While using SSL is certainly the easier of the two choices, there are a number of reasons why WS-Security is generally superior.

SSL Provides In-Transit Security Only

The basic mechanism behind SSL is that the client encrypts all of the requests based on a key retrieved from a third party.  When the request is received at the destination, it is decrypted and presented to the service.  This is a well understood process.  However, when you look a little deeper, you'll begin to realize that the request is only encrypted while it is travelling between the client and the server.  Once it hits the server, it is decrypted from that moment on.

To be completely accurately, it might not even need to hit the server to be decrypted.  If, for example, you have a proxy server in front of you web server, it is possible that the decryption certificate has been installed there.  That way the server can examine the message to determine the correct routing.  However, the message may not be re-encrypted before it is set to the web server that will actually handle the request.  So now that  'secure' request is travelling along a network in clear text.  Granted, the network that is travels along is quite likely the internal one for the company hosting the server.  Still, there is the possibility that sensitive data can be picked up.

Further, what if the web service logs all of the incoming requests into a database.  Now not only does the request travel unencrypted across the wire, but it is also stored in a format for all to see.

WS-Security alleviates this problem by maintaining its encryption right up to the point where the request is being process.  Also, if the request is logged, the logged version will quite likely be encrypted (the logging portion of the service *could* log the message in unencrypted form, but it would have to do so explicitly).

Targeted Security

If SSL is used to encrypt a web service request, it's an all or nothing proposition.  SSL secures the entire message, whether all of it is sensitive or not.  WS-Security allows you to secure only that part (or parts) of the message that needs to be secured.  Given that encryption/decryption is not a cheap operatio, this can be a performance boost.

It is also possible with WS-Security to secure different parts of the message using different keys or even different algorithems.  This allows separates parts of the message to be read by different people without exposing other, unneeded information.

Faster Routing

Although not part of the mainstream yet, look for intelligent load balancing based on the content of incoming requests in the near future.  When this does happen, wouldn't it be better not to have the router decrypt the request before determining where it should go?

So given all of this, when why would you need to use SSL?  Because there are still a lot of people for whom SSL is the ultimate in security over the web.  Without the comfort of https, some companies feel that their information is being sent naked into the wild.  Not true, but it's not always appropriate to get into screaming matches with clients. ;)  Sigh.  I guess more educating is in order.

Update:  My colleague, John Lam, pointed out that my comment about the key to SSL encryption being retrieved from a third party was inaccurate.  In actuality, the SSL mechanism involves the following steps (taken from here)

  1. A browser requests a secure page (usually https://).

  2. The web server sends its public key with its certificate.

  3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.

  4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.

  5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.

  6. The web server sends back the requested html document and http data encrypted with the symmetric key.

  7. The browser decrypts the http data and html document using the symmetric key and displays the information

You will notice that, while there is a third party involved in validating the certificate, the key does not come from the third party but from the server.

John also mentioned that the availability of SSL Accelerators makes the performance argument moot.  I don't agree with this.  While SSL Accelerators certainly increase the throughput of secured sites, we need to compare apples to apples.  There are also XML Accelerators available in hardware to decrypt incoming requests.  Certainly using hardware makes it easier to justify staying with just SSL, all you're really doing is pushing the bottleneck further out. Ultimately, because encryption is a computationally expensive operation, the less that gets encrypted the greater the overall throughput.

Finally, there is one further reason to choose WS-Security over SSL that I forgot to mention.  SSL is closely tied to HTTP.  Which is to say that SSL can't be used if the mechanism for transporting service requests is something other than HTTP.  At the moment, this isn't the case for the vast majority of requests.  But there are already SOA examples using UDP and SMTP as the transport.  WS-Security works independently of the underlying protocol, making it much easier to adapt to whatever the future requires.