Silverlight, WCF and Secure communication

Silverlight only supports the "basicHttpBinding" WCF binding which sends all messages in the clear, unlike the "wsHttpBinding" binding.

How can we overcome this limitation? Peter Bromberg wrote about it here. However his suggest uses reflection and changes the actual object data when it does the encryption. Because the data in your object is changed that could cause unwanted changes to propogate. To avoid this you could use wrapper objects or even do a deep-level clone (using reflection, il emit, etc.) to create a copy of the object, encrypt its data, then allow it to be transmitted.

Also his example only deals with string data, but numeric and other types of basic data are also important. Encrypting string data doesn't do much good if your package is mostly numeric, say financial information, that could potentially be exploited too.

Perhaps another way of approaching the situation is to use a message package that contains encrypted data objects. Either the package could be at a high level that contains many objects or on a per object basis. Obviously when using a message package at a high level you lose fidelity and the client does not have a hard contract with the server concerning the contents of the service call. Rather all he has is a soft contract based on documentation. An psuedo-code example of this would be.

MessagePackage
{
string data;
string type;
}

Data: List

Step 1: Serialize data.
Step 2: Encrypt data.
Step 3: Create message package with the type name and the data.

The client would then

Step 1: Decrypt data in package.
Step 2: Deserialize data.

Again, we don't have a hard contract to know exactly what data has been stored in the package, only what we've been told it should be.

Another way of approach it would be a per object message package as above. Using the same data from before, our new process would look like the following:

MessageElementPackage
{
string data;
Type type;
}

Step 1: Serialize individual data elements.
Step 2: Encrypt individual data elements.
Step 3: Create individual message element packages for each data data element.
Step 4: Send message package elements as a List.

The client would then

Step 1: Decrypt data for each message element package.
Step 2: Deserialize each data element.
Step 3: Create a List of deserialized data.

The package would at least contain the a semi-hard contract in the Type property that could be checked and verified. However its still a soft contract as opposed to hard contract.

Neither of these options are really all that attractive as they lose a lot of what is benefitial about WCF, the hard contracts for data that is transmitted between server and client.

Of course, if you are using SSL then this is a moot point and would add additional, and unncessary, overhead.