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).

The "Unable to remove directory "bin\Release\app.publish\" Azure packaging error

Just a quick note on an error I often run into when I'm working on my Azure applications. I usually create Azure packages and upload them by hand through the Azure management portal. Ever so often I get the following error when I create the package in Visual Studio (2012).

Unable to remove directory "bin\Release\app.publish\". Access to the path 'AzureStartupTest.Azure.cspkg' is denied.

 Turns out someone is holding on to that file!!

When you create an Azure package, VS opens a file explorer window showing you the published files. You should close this explorer window before you run the package command again. It also turns out that Internet Explorer holds on to the file if you've uploaded it through the Azure management portal. If you refresh (F5) the management portal, IE lets go of the file and you can run the package command again without problems.

It seems I'm not the only one on the Internet running into this problem. I found some shady advice out there, such as rebooting your computer or disabling the antivirus to make the problem go away. I would recommend neither. With the aforementioned trick you can safely re-enable your antivirus and get back to work.

Ramping up ASP.NET session security

OWASP recently released their Top Ten 2013 list of web application vulnerabilities. If you compare the list to the 2010 version you’ll see that Broken Authentication and Session Management has moved up to second place, pushing Cross Site Scripting (XSS) down to third place. Apparently authentication and session related issues are moving up in the world!

It’s not that surprising, there’s so many things that can go wrong. It seems that authentication and session management is so difficult to get right that even the big players occasionally get in trouble. I’ve blogged earlier about a Google 2-step verification vulnerability I discovered back when they were rolling out the system (yes, I admit it took more patience than effort to find that one), and if you do a Google search for "authentication flaw" you’ll get plenty of hits for many high profile sites. This indicates that we need to tighten up our authentication and session management. In this post we’ll focus on some issues related to session management, and at the end I have an announcement to make!

OWASP has a great guide on what you should test for in your session management. If you’re familiar with the Microsoft SDL you’ve probably noticed that it also has a set of recommendations for session management. We’ll dig into some of the details of ASP.NET session management to see how it fares against some of these requirements.

First things first, we’ll need to set the scene with an overview of how ASP.NET handles identities and sessions and then we’ll return to the requirements.

Outlook.com, custom domains, and ActiveSync

Microsoft's widely used e-mail service Hotmail was recently overhauled and rebranded Outlook.com. One of the less known services they provide is the support for custom domains. A couple of months ago, I was looking for a new (preferably free) e-mail service for my personal domain. It turned out Outlook.com had everything I needed!

To set up a custom domain, you'll first have to log in to the Windows Live Admin Center with your Microsoft account (I used my good ol' Hotmail account). There you'll add your custom domain, and you'll get instructions on how to set up DNS etc. You can choose between closed membership, i.e. you'll register the e-mail accounts yourself, or open membership which lets users register e-mail accounts under your domain themselves. The setup was straightforward, so I won't repeat the steps here. You initially get a limit of 50 e-mail accounts for your custom domain.

Some important ASP.NET 4.5 security improvements

The .NET 4.5 framework was released a couple of months ago and it included several improvements in the security area. To benefit from these improvements you need to do a few changes to you application's configuration file. The documentation is a bit scattered over MSDN and MSFT blogs, I figured I'd collect them here for easy reference.

The ASP.NET team published a nice article on What's New in ASP.NET 4.5 and Visual Studio 2012. There you'll learn that:

• There are changes to the ASP.NET request validation, it now supports deferred (lazy) validation, as well as giving the option to fetch data unvalidated.
• The AntiXSS library is included in the framework.

However, there's no mention of two other important changes:

• There are significant Cryptographic Improvements in ASP.NET 4.5. Read it! This is important stuff!
• Windows Identity Foundation is now included in the framework, referred to as WIF 4.5.

To take advantage of these new bits you'll have to do a bit of configuration, we'll get into that right away.

How to encrypt a custom configuration section in ASP.NET

Recently I wrote a piece of software that needed some configurable secrets — and they needed to be VERY secret. Consequently, I had to encrypt a custom configuration section. Unfortunately, I quickly ran into trouble and got an error message along the lines of:

Encrypting configuration section...
An error occurred creating the configuration section handler for myConfigSection: Could not load file or assembly 'MyAssembly, Version=2.0.0.0, Culture=neutral' or one of its dependencies. The system cannot find the file specified.
...
Failed!

Disheartening, eh? I looked to the Internet and the advice seemed to be to copy the "missing" assembly to the .NET framework folder. I strongly suggest you don't do that, messing around in the framework's folder is not recommended. That folder belongs to Microsoft.

Fortunately I found a much easier workaround. I'll give an example where I encrypt the configuration section for the NWebsec security library, in the DemoSiteWebForms project that's part of the project's solution.