Google Chrome withstands security testing

From Ars Technica:

A recent contest at CanSecWest, an event that brings together some of the most skilled experts in the security community, has demonstrated that the three most popular browser are susceptible to security bugs despite the vigilance and engineering prowess of their creators. Firefox, Safari, and Internet Explorer were all exploited during the Pwn2Own competition that took place at the conference. Google's Chrome browser, however, was the only one left standing—a victory that security researchers attribute to its innovative sandbox feature.

Web Services Security Guide for WCF

Microsoft Patterns and Practices has released the WCF security guide.

Parts

Part I, "Security Fundamentals for Web Services"
Part II, "Fundamentals of WCF Security"
Part III, "Intranet Application Scenarios"
Part IV, "Internet Application Scenarios"

WCF Security Guide

The 2nd beta of the WCF Security Guide has been released by the Microsoft patterns and practices group.

Common WCF Security Scenarios

Internet Unsecured Client and Service

An example of a public, unsecured client and service.

Intranet Unsecured Client and Service

A basic Windows Communication Foundation (WCF) service developed to provide information on a secure private network to a WCF application.
Transport Security with Basic Authentication
The application allows clients to log on using custom authentication.

Transport Security with Windows Authentication
Shows a client and service secured by Windows security.

Transport Security with an Anonymous Client
This scenario uses transport security (such as HTTPS) to ensure confidentiality and integrity.

Transport Security with Certificate Authentication
Shows a client and service secured by a certificate.

Message Security with an Anonymous Client
Shows a client and service secured by WCF message security.

Message Security with a User Name Client
The client is a Windows Forms application that allows clients to log on using a domain user name and password.

Message Security with a Certificate Client
Servers have certificates, and each client has a certificate. A security context is established through Transport Layer Security (TLS) negotiation.

Message Security with a Windows Client
A variation of the certificate client. Servers have certificates, and each client has a certificate. A security context is established through TLS negotiation.

Message Security with a Windows Client without Credential Negotiation
Shows a client and service secured by a Kerberos domain.

Message Security with Mutual Certificates
Servers have certificates, and each client has a certificate. The server certificate is distributed with the application and is available out of band.

Message Security with Issued Tokens
Federated security that enables the establishment of trust between independent domains.

Trusted Subsystem
A client accesses one or more Web services that are distributed across a network. The Web services access additional resources (such as databases or other Web services) that must be secured.

from MSDN

Using a Client Certificate to Restrict Access to a WCF Service Method

This post is based on this article.

Service Configuration

We are going to configure our service for Transport and Message Security with a client certificate, and we are going to add an attribute to a service method to restrict access only to clients that present the correct certificate. We will use the WSHttpBinding. The port is already configured for https from this post.

First configure the binding:

WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
binding.Security.Message.ClientCredentialType = MessageCredentialType.Certificate;

To designate the certificate that is permitted to access the service method, you will need to know the subject name and thumbprint of the certificate. Import System.Security.Permissions and decorate the method with the following attribute:

[PrincipalPermission(SecurityAction.Demand,
Name = "CN=joeuser.example.com; ddf5066afceb34a95ff75795ced345ff549464202")]

Here the Name parameter is equal to the certificate Subject followed by a semi-colon, a space, then the certificate Thumbprint. Multiple attributes can be added to support more than one client certificate. The final configuration option is to set the mode on the service to map the certificate information to this format (Subject; Thumbprint). This is done through the ServiceBehaviorAuthorizationMode (set it to UseAspNetRoles). You will need to import System.ServiceModel.Description.

ServiceHost host = ...
ServiceAuthorizationBehavior b = host.Description.Behaviors.Find();
b.PrincipalPermissionMode = PrincipalPermissionMode.UseAspNetRoles;

Client Configuration

Now we need to tell the client which certificate to present to the service. The same method is called whether you are using a Client Proxy or have created a ChannelFactory. I will show the example using a ChannelFactory. This must be done before creating the Channel.

factory.Credentials.ClientCertificate.SetCertificate(
System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
System.Security.Cryptography.X509Certificates.StoreName.My,
System.Security.Cryptography.X509Certificates.X509FindType.FindBySerialNumber,
"1a2fa58b000000003a5c");

In this case, I am looking it up by Serial Number, but the certificate can be found by Thumbprint, Subject Name, or a number of other fields. Again, use the MMC Certificate Snap-in to look up the information.

That's all there is to it.

Configuring a WCF Binding for https

Both BasicHttpBinding and WSHttpBinding support Transport Security (https). However, neither do it by default. The binding must be configured correctly. Here is how to do it in code:

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.Transport;

or simply

BasicHttpBinding binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);

For WSHttpBinding:

WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.
TransportWithMessageCredential;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

Here is a summary of the System-provided Bindings. Note that the NetTcp bindings have Transport security (encryption) enabled by default.

Configuring a port for SSL/TLS

Note that what we usually refer to as SSL is now really TLS (Transport Layer Security).
--------------
If you want to use Transport Security with your http WCF service, there are two options:

• Host your service in IIS.
• Configure a port for SSL/TLS and self-host your web service. This will allow you to create a Windows Service that runs your web service over https.

Either way, you will need a certificate that identifies your host as trusted to the client and provides the public and private keys that are used for negotiating the encrypted transfer. For a production environment you will need to obtain the certificate from a Certificate Authority (CA).

For development and testing, we can create our own CA and then issue a test certificate from that CA. It can't be used in production because the clients will not have a trusted relationship with that CA, but we will configure our test client to trust it. You will need the MMC snap-in from my previous post. Run MMC and Open the SSL Snap-in that you previously configured. This way you will see the certificates as they are created in the Certificate Store.

You will also need the makecert.exe tool. You will have it if you have Visual Studio or the .NET Framework SDK. Go to your Start Menu and run the appropriate Command Line Environment.

Finally, you will need httpcfg.exe (download for Windows XP SP2). Vista users will use netsh.exe. This tool will be used to associate the certificate with the port.

The instructions for creating the certificate are based on Chris Jackson's post.

Create the CA certificate

At the command line (all one command),

makecert -pe -n "CN=Test and Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test and Dev Root Authority.cer"

Now, if you look in the Local Computer (-sr LocalMachine) section of the SSL Certificates MMC Console, you will find a certificate in the Personal\Certificates folder (-ss my). You may need to refresh (F5) the folder.

Create the Test Certificate

Next, we will create the certificate to be assigned to the port. The name of the certificate must match the hostname in the URL that the client will use to access the service. Otherwise, the client will refuse to complete the handshake. Sometimes you get this error in your browser when the certificate name does not match the URL. Just as in the browser scenario, it is possible to configure the WCF client to ignore the mismatch, but I will leave that to a future post.

If you want to access the service via https://testserver:8081/service, enter the following at the command line (all one command),

makecert -pe -n "CN=testserver" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test and Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 "Test and Dev SSL.cer"

Again, you will find a new certificate in the Personal\Certificates folder on the Local Computer main node. If you double-click to view it you will see that it is not trusted. That is because your computer does not trust the CA certificate that we made and used to sign the testserver certificate.

Trust the CA

To trust the new CA certificate drag it from the Personal\Certificates folder to the Trusted Root Certificate Authorities\Certificates folder below it. Now if you open the testserver certificate, it will show as valid.

Configure the port for https

The last step is to configure a port (8081 in this example) to use the testserver certificate for SSL/TLS. The HTTP.SYS driver will use the certificate's thumbprint to look it up in the certificate store, so open the testserver certificate and go to the details tab. Scroll to the bottom and select the Thumbprint property. The text box below it will show the value with spaces:
71 d1 ea 2b 7d 2e cf 75 ac a5 60 1f 66 94 9b b6 ee aa be 44.

We will use the httpcfg.exe command to configure it. It is probably located in C:\Program Files\Support Tools. You will need to remove the spaces from the thumbprint hash value.

httpcfg set ssl -i 0.0.0.0:8081 -h 71d1ea2b7d2ecf75aca5601f66949bb6eeaabe44 -f 2

The -f 2 option will allow us to use client certificates to authenticte the client in a later post. The 0.0.0.0 IP address means all IP addesses on the computer. If you only want to associate it with a single IP address, use that one.

Now you can configure your service to listen on https.

Viewing SSL/TLS Certificates

When setting up self-hosted WCF services to run under https, it's useful to be able to view the Certificates that are installed and discover their thumbprints (hash values).

These articles explain:

How to View Certificates with the MMC Snap-in.

How to retrieve the Thumbprint of a Certificate.

Once you have the hash value for the certificate, it is used as a lookup by the HTTP.SYS driver to locate the server certificate that will be used for https encryption/decryption. I'll explain how to configure the HTTP.SYS driver for SSL/TLS in a future post.