Hardening Windows Server 2008/2012 and Azure SSL/TLS configuration

I guess it was long overdue for me to follow up on my Hardening Windows Server 2003 SSL/TLS configuration and Windows server 2003 vs 2008, SSL/TLS comparison posts. They were two of my very first blog posts and they still receive a decent amount of traffic. The world has fortunately moved forward since then, so in this blog post we’ll have a look at the default configuration of recent Windows Server (WS) versions in light of the latest recommendations from SSL Labs. We’ll keep the discussion at a reasonably high level, but I’ve included references to more in-depth information along the way for those who want to dig into the details. We’ll finish off with an announcement (Hint: it might have something to do with TLS configuration and Windows Azure).

How to enable WIF token replay detection

Windows Identity Foundation (WIF) is vulnerable to replay of security tokens in its default configuration. The "Replay Detection" article on MSDN presents a good example of how things can go wrong without the replay detection (why do everyone have to use online banking as their example?):

As another example, suppose that a user opens a browser on a public kiosk, logs on to a bank account using the bank’s Web site, logs off and leaves, but does not close the browser. The response to the user’s logon page, which contains the STS token, is still in the browser’s history. Another person could then browse back to that response page and replay it, which would repost the STS token to the bank’s Web site.

This scenario is very much real and it does not involve any fancy hacking techniques. All you need is a browser and a "back" button. You'll find some scattered references on the Internet to the solution of the problem, the tokenReplayDetection configuration setting. You'll find a mention of the configuration element in the WIF FAQ on Technet and in the WIF book, but you'll find the most helpful explanation in the ACS security guidelines.

I'll cut to the chase, here's the config to enable the token replay detection. Please don't use the parameters as is, read the security considerations and tweak the values accordingly. Seriously.

How to give IIS access to private keys

If one of your ASP.NET applications need to access to a certificate from the certificate store along with its private key, you'll probably run into trouble. The private key is saved in a special file with an unguessable name. It's not readable for everyone (for obvious reasons). The lack of file access is not very intuitive, as you can see the certificate in the Certificate MMC snap-in, and it will claim that "this certificate has a corresponding private key". You'll still have to give the application pool's user read access to the key.


There are some differences in how to do this for the 2008 R2 and the 2003 server, here's a short explanation and some useful resources for both versions.

Customized .Net configuration the easy way

I stumbled across a great series of articles on how the .Net configuration features can be used:

Unraveling the Mysteries of .NET 2.0 Configuration by Jon Rista.

You'll find the MDSN documentation for System.Configuration here.

I've started creating my own configuration sections and they yield several advantages:

• No XML parsing
• No more misuse of appsettings
• Extremely readable code
• Easy validation of configuration values
• Understandable error messages for configuration errors

So check out Rista's series of articles and start creating more robust and understandable custom configuration code!