Jump to navigation

Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.
Otherwise you may find some unperfect stuff here...


Back to WSE

Now that code signing, both strongnames and authenticode, support are included into corlib, with a big thanks to Zoltan for the runtime part, let's get back to Web Services Enhancements.

Lately Todd has been doing a great job to support the still in-flux, as in breaking changes, WSE 2 Technical Preview. As for myself I've set my own goal - I wanna to make a secure web service sample ;-). No kidding - not just some samples about security but something that may prove useful in some real life problems. Of course this will be entirely done using Mono:: while implementing WS-Security.

As with many of my stories it all starts with someone using a client application (I never said this would be intriguing). The user needs to authenticate to a web service. Using X.509 certificates would be cool, and make my professional life much easier, but that's just not reality (no sci-fi here). Real dictates that most users still authenticate with password (and associated office tools). So let's do this right and start by hashing the password (PasswordOptions.SendHashed) so no one can read it in transit.

The next step would be assure the confidentiality of the user's requests. Nobody want to see it's credit card numbers transmitted in clear on the internet (and only few actually cares that it's not the way credit card numbers are stolen on the net). Here is a good, real life example, of how X.509 certificates are used today on the internet. Servers have their own certificates, binded to their DNS entries, so you can establish a trusted link from a client to the server (and yes directions matters). This can be done by using SSL/TLS or by using XML Encryption.

But we're still missing something between the client and the server. Anyone can use the server X.509 certificate, so anyone can establish a trusted communication between itself and the server. What we are lacking (most) is integrity - we do not want someone else to get, somewhere somehow, your post-it credentials. The timestamp inside the UsernameToken may help by limiting the vulnerability window - it's a nice addition but it's not enough. For this we need digital signature which is possible, albeit with very limited non-repudiation, using a password. However this isn't very well documented in the current WS-Security specifications but it is possible using the WSE's UsernameToken.SignatureKey.

So without required any major investment/burden on the user, like a PKI, we can send an request to a web service with a good level of trust. Now what's the server gonna do with it ? With a little luck (and interop) the service will process your request and sent you back a response. If you used SSL/TLS to send your request then the same encrypted channel will be used to send you back the response. In this case this works well because you have demonstrated your trust on the server or you wouldn't have sent your request to it, would you ?

But, the interesting case is, what happens if you used XML Encryption ? It was easy (well it may look so) to use the server's certificate to encrypt your request but the server can't do the same - as the users don't have their own X.509 certificate (that's my story and I'm sticking to it). For this we need a shared secret between the client and the server. The server can use this secret, as a symmetric key, to encrypt it's response. Getting the secret from the user to the server can be done by including it into, the encrypted part, the request.

What about the integrity of the response ? This one is easy because the server can sign the response using it's own certificate. The users just have to verify the response's signature. Again trust of the server is implied by the fact that you wouldn't have sent the request if you didn't trust the server.

This should make an interesting sample and keep me busy, both coding and blogging, for some time...

Questions: How do you trust the servers ? the certificates ? the DNS entries ? or your own computer ? if you can't I would suggest you my wireless brick but it's not for sale ;-)

10/18/2003 23:46:38 | Comments

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.