Have you ever used a public WiFi in a coffee shop? Or did you use one in an airport, hotel, restaurant or a museum? I bet you were wondering how safe these networks are and whether your HTTP traffic can be sniffed by anyone nearby! Well, to keep the answer short, public WiFi network at anything but safe and the traffic can be sniffed with ease in almost any available public WiFi.

On the other hand, did you ever try to watch movies on Netflix, listen to some good music on Spotify or Internet radio on Pandora from an Eastern-European country (e.g. Romania), just to find out that these services don’t work in Romania (yet)?

Well, Azure is here to the rescue! During this article you’ll go through all the steps necessary to create a VM hosted in one of Azure’s data centers so that all your Internet traffic goes through a secure VPN tunnel to the data center. In the end, this basically means that your traffic will look as if originates from within Azure and thus you’ll be able to use the kind of services mentioned earlier.

The infrastructure schema of what we’re trying to achieve looks something like this (please try to bear with me here – I’m totally aware my drawing skills are close to nonexistent):

Untitled

Prerequisites

There are a few requirements in order to successfully complete this step-by-step guide:

  • you will most certainly need an Azure subscription. You can either use a 30-days free trial account or a Pay-As-You-Go account. Additionally, if you have an MSDN subscription, you can also use your Azure credits, which are part of your benefits as an MSDN subscriber. Here’s a link on how to sign-up for a 30-day trial account today using your Microsoft Account
  • a SSL certificate. Yes again, there are a few options here: the obvious one is to buy a SSL certificate from a publicly available Certificate Authority (CA), or to create a self-signed certificate which you’ll manually install in the Trusted Root Certificate Authority container. In order to create self signed certificates, you can either use makecert.exe, a utility which comes with any installation of Visual Studio 2013 (or 2012, for that matter) and/or Windows SDK, or selfssl.exe, part of the lightweight IIS6 Resource Kit.

Read More →

One other situation I recently came across was regarding WIF and the pipeline security applied to it. Basically, due to up-scaling a project from one server (I know…) to multiple-instances, the app kept going into infinite redirect loops (HTTP 302), thus not allowing users to wander around the app. The case like this:

1. The user first visits the page

2. The user clicks anything in the page

3. The app goes into infinite 302.

The situation was cause by the security mechanisms the make the ASP.NET session authentication secure. Basically, by default, the DPAPI security providers are used. This basically states that for every single new session, a random key is generated that the user can wander around. That key is normally kept in the session providers, but is related to the keys used by the machine. Obviously, in a webfarm scenario (such as a multi-instance cloud service), DPAPI is useless and causes a CryptographicException to be thrown, since the FedAuth cookie gets encrypted by one machine and when you redo a request to your app, the cookie can no longer we decrypted.

If, for any case, you have a custom error page and if you, like in my case, must have the security mechanisms inside a Master page and mostly if the Error page inherits the Master page, you will, like me, get an infinite redirect loop (302).

The solution to this is to configure (using the web.config file) your IIS machines to use another security pipeline mechanism, such as MachineKey encryption. Moreover, it is obviously required to configure a static machine key and validation key, yet most Google-related results for this situation fail to remember that such a setting is required. Otherwise, the different machines in the web farm still get different keys and the FedAuth cookie won’t decrypted, failing in the CryptographicException all over again.

The required configuration for web.config for replacing your DPAPI security mechanisms with MachineKey cryptography is:

<securityTokenHandlers>

<add type=”System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

<remove type=”System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

</securityTokenHandlers>

As for the machine key, you have to choose an appropiate key size (only HEXA-DEC chars), as mentioned on this MSDN article on machinekey configuration in ASP.NET 2.0 (I know it’s old, but it’s still valid for ASP.NET 4.0).

Choose an appropriate key size. The recommended key lengths are as follows:

  • For SHA1, set the validationKey to 64 bytes (128 hexadecimal characters).
  • For AES, set the decryptionKey to 32 bytes (64 hexadecimal characters).
  • For 3DES, set the decryptionKey to 24 bytes (48 hexadecimal characters).

A.