Encrypting Data Passed Between the Server and the Client

A common cracking technique is to sniff data as it travels over the network, capture this traffic, and extract any sensitive data to potentially be used for ulterior motives. You can try a form of this yourself by using a tool such as the Fiddler Web Debugger (a free tool that you can download from http://www.fiddler2.com) to sniff and capture network traffic on your machine. You may have also heard of a Firefox extension named Firesheep, which sniffs network traffic looking for cookies being passed between the machines on the network and certain web sites (such as Facebook) over unencrypted connections. Once a cookie is obtained, it allows you to impersonate that user on the web site and browse it as if you were them, demonstrating how vital it is to encrypt all traffic between the server and your application.

By default, RIA Services uses binary encoding when transferring data over the network, but it's still relatively easy to read with a Fiddler add-in, so it should not be considered encrypted traffic.

Ideally, if you are passing sensitive data between the server and the client, you want to encrypt this traffic by communicating over HTTPS, using SSL, to protect it from this sort of sniffing. This requires a server certificate to be purchased from a certification authority and installed on your IIS server (a full discussion on doing so is beyond the scope of this chapter). Alternatively, you can use a self-signed certificate for development and testing purposes. IIS 7.0 on Windows Vista/7 makes this easy to create, as described by Scott Guthrie in this blog post: http://weblogs.asp.net/scottgu/archive/2007/04/06/tip-trick-enabling-ssl-on-iis7-using-self-signed-certificates.aspx.

Assuming you have already installed a server certificate, let's look at what you need to do to get the service operating over HTTPS.

Enforcing that communication must be over HTTPS is specified at the service level and is simply a case of setting the RequiresSecureEndpoint property of the EnableClientAccess attribute to true for each domain service that must be accessed securely, including the AuthenticationService. Any requests to domain services over HTTP that have this property set to true will be denied access.

It's not necessary that the Silverlight application itself is accessed over HTTPS—you can access it over HTTP and then require server/client communication to be over HTTPS with this method:

However, note that when you deliver the Silverlight application via HTTP but communicate with the domain services via HTTPS, you are effectively communicating with a different domain than the application's source. This means that you must implement a cross-domain access policy file that allows cross-scheme access, as will be described in the next section.