Demystifying WCF and SSL – Part 1

Over the past years I have come across many articles that do a very nice job of explaining the deep intricacies of security and authentication as offered by WCF. There are some excellent blog posts and msdn articles which present a deep dive of each individual security option that you can leverage with WCF. However when I started writing a sample application to experiment and play around with how can I use SSL for transport security with WCF, how do I setup a test environment, what makes using SSL different than wsHttpBinding’s native behaviour etc. I could not find one article that could act as a one stop shop and give me a step by step of what I need to setup test harness that shows how to create and configure SSL certificates on a client/server and how to use them with WCF.

So I have decided to write a series of three posts where I will try and present concrete direction on

  1. What is the default behaviour of wsHttpBinding, what security is provided by this binding.
  2. How can you create some test SSL certificates for your local machines and set them up
  3. How do you write a sample app that shows configuring a WCF service to use wsHttpBinding and then TransportWithMessageSecurity using SSL certs.

In this post I would take up the first point and try and shed some light on the default behaviour of wsHttpBinding

Default Behaviour of wsHttpBinding

The default behaviour of wsHttpBinding is to (in simple words) provide security by encrypting(hashing) message. A full discussion on how this is achieved and what is involved in achieving this would be out of scope of this post but in simple terms this is what I mean

If you have a WCF service configured to listen on a wsHttpBinding enabled endpoint with no further customization to the end point behaviour or the binding then the messages exchanged with this service will be secured on a message level. This means that using a tool such as Fiddler you can see what messages are exchanged but will not be able to make sense of them.

To see this in action, download the source code I have attached with this article and run it by pressing F5. Then open up the WcfTestClient tool that comes up with Visual Studio. You can do this by opening up the visual studio command prompt (Start or Orb->All Programs -> Microsoft Visual Studio 2010 -> Visual Studio Tools)

Visual Studio 2010 Tools

Then type WcfTestClient and hit Enter. This should open up the WcfTestClient tool. Once the tool has been launched. Click File-> Add Service and enter this as the service address

http://{Your Local Machine Name}:27050/Services/SampleService.svc

This should show something like this

Now before going any further download and install Fiddler from here. Fiddler is an excellent Http debugging tool that allows you to see the Http requests/response originating from your machine.

Once you have Fiddler running, double click the GetValue() method as shown in the above screenshot then enter a string value for the Value field (I have entered “ds”) above and click the Invoke button.

When you click the Invoke button some log entries with your machine name should appear in Fiddler. Examine those at your leisure. You would notice that while both the requests and response are in clear text, the message payloads are encrypted! I have shown a screenshot of my Fiddler window below.


What! wsHttp can have “no” security too !?

So as one last “fun” step let’s force wsHttp to pretend and be like one of its siblings and tell it “not” use any security whatsoever. So in the web.config file, find these lines and uncomment them. Stop and Start your VS project.



This is where we tell our WCF Service to expose “another” end point using wsHttpBinding. In addition we are also letting WCF know to use a binding by the name “NoSecurity” for this end point. This binding is defined in the web.config file as follows

        <binding name="NoSecurity">
          <security mode="None">
            <message clientCredentialType="None" negotiateServiceCredential="false"/>

In this binding we have forced WCF to not use any security at all. On this end point all communication will now happen in clear text. I will quickly summarise how to verify that this end point works as expected.

Go back to your WCF Test client. Right click the Service and select “Refresh Service”.

You should now see two nodes come up as shown below.

Invoke the GetValue on both of them. One of them will show clear text Fiddler trace as shown below (you can find out which one will emit the trace if you look at the Config file and find out which service is using the /nosec binding)

Fiddler shows unencrypted text

So this finishes up my first post on this blog and the first post in the Demystifying WCF and SSL series. In the next part I will give you the concrete steps on how to create a SSL certificate for your test environment.

Download the code samples here SampleWcfServices

Leave a Comment

Your email address will not be published.

1 Trackback

  1. Nik's Corner – Demystifying WCF and SSL – Part 2 – Creating SSL Certificates (Pingback)