Windows CardSpace will work without HTTPS, too

In short: I discuss a new feature, introduced by the .NET framework 3.5 and by a (future) update of IE, which enables the use of CardSpace also on websites on normal http (as opposed to https).

 

Back in January I was asking Caleb (SDET on the CardSpace team and most excellent buddy author) when he would have started blogging. It took 9 months, but it eventually worked! Not only he is going to blog, but he got the entire team to do it… if I were you I would subscribe the feed this instant! (being me, I can actually take a 10 mins walk and go bug the guys directly in their lairs).

In the first technical post Ruchi presents a very important innovation, introduced with the .NET framework 3.5: the capability of using CardSpace also with websites without SSL. She goes into the detail of system requirements, how the new functionality can be leveraged and how things like PPID generation and transmission of the RP identity in the RST are affected by the new regimen. I won’t repeat those details here: I invite you to read that post and consider it the main reference on the subject. Here I’ll just highlight few points, largely derived from the QA sessions we had internally when the new feature was first discussed.

This change opens up the advantages of using CardSpace to a significantly wider range of scenarios

I know what you’re thinking, or at least what many of you are thinking. A cert comes down for just few bucks, come on! Actually, the cert in itself is rarely the problem. The fact is that there are many situations in which you don’t own directly the web space your pages are occupying. Sometimes you have to share it with many other websites, and/or your URI is a virtual dir of a domain you don’t own: in that case the certificate would not represent you, because that would be neglecting everybody else on the same server. Sometimes you can’t run code on the web server with full privileges. Some other time the hoster won’t give to your web app any access to the SSL cert private key. All those problems are non-issues if you own your own website (and in fact chances are that those problems would have to be solved anyway for reasons orthogonal to cardspace usage); but if you just want to run your blog, you may not necessarily want to go through the hassle of fixing them. The NoSSL innovation puts the cardspace option back in the game, keeping the main security features unchanged while clearly warning the user when things may behave differently than in the “classic” process. Curious about the details? Read on. 

We allow you to send tokens to websites without using HTTPS. So what?

Let’s think for a moment about the consequences of this very basic change.

• whatever data we send can be seen in transit; unless we encrypt at a different level (message, anyone?) Eve can finally have a good peek at the messages that Alice sends to Bob


• the website we are contacting has no longer a certificate associated; Trent (the CA) does not guarantee anymore that www.bob.ext is really the uri of the web properties of Contoso Inc.

For tokens rendered via self issued cards, the loss of confidentiality is real. We make that very clear in the UI, so that the user is in control of the modes in which the information will be shared. If you think about it, that’s actually much better user control than what happens when you click any page element that elicits a HTTP postback: here we make a fuss about the absence of encryption, so that you can take an informed decision about sending or not sending, there the browser just does its postback without warning.

Now that we solved the confidentiality part (we make clear whne the connection is in the clear, so that the suer can decide not to share sensitive information) Now comes the beautiful part. What about authentication strenght? What do we lose if we don’t use encryption? The answer is almost nothing. If you read the post about UniqueID, you know why: however let me reiterate the concept here. As Ruchi mentions, the self issued token is still signed! Ultimately What the RP verifies is the capability of the subject of signing the token with a certain key. As long as there’s a signature on the token this check can still be performed, HTTPS or not. Picture follows.

The card has the usual keys (public black, private red. hmmm…). The website stores in the membership DB the usual derivative of the public key (UniqueID). The token travels in the clear (glass pipe). Once the token is received, the website checks that the signature was performed with the right key. That’s it.

 

Can the content of the token be read? Sure! Can the information in it be used for stealing the user identity? NO, if your web site didn’t rely on a shared secret that you send in that token (like you would, if you would use erroneously the PPID). There is the usual little problem of token replay, which can be mitigated by a very short expiration time.
So, let me stress this one more time: we are still using asymmetric cryptography here. The UniqueID check is as solid as it with HTTPS, losing the transport encryption does not affect it.

 

That’s for personal cards. What about managed cards? Here there’s more control on the STS side, so how this change will be handled is determined by the policies of every IP. The STS can still encrypt the token, provided that certificate used by the RP is known by the IP (HTTPS is not the only way of publishing certificates): in that case the loss of transport security is really of no concern (and here I can resurrect a really old post for giving the idea. Ah, old toshiba M200… my first tablet. But I digress). The IP can still receive info about the intended RP (though just via URI rather than cert), and the information that the transaction will be on normal HTTP is available for it to decide what course of action is best. The IP can even opt out from NoSSL scenarios altogether, simply by flagging its cards accordingly (again, see Ruchi’s post).

You may not be able to play with this feature just yet

The NoSSL magic arises from the synergy of the new .NET framework 3.5 (currently in beta 2) and a modification that ships with an update to IE. Such an update is in Vista SP1, which is not available for the general public just yet. The official post has some more details, but not much more.

However now you know it’s coming, and from the developer experience it does not really require dramatic modifications: so once it will be available you’ll be able to use it right away!

That’s it. Kim anticipated it would have happened in a post in July, and today here we are. This is a an enhancement that brings great potential, and I am sure you’ll have a lot of questions. As usual, speak your mind! 🙂