How this module works

This module is, in fact, very simple. The vast majority of the code is hoop jumping and related to the management GUI.

At it's core this module does two things:

1. Upon initiation of the module for a site, if HSTS is enabled an event handler is attached to every response just before the headers are sent.
2. This event, if attached, checks if the request is secure and, if so, injects the HSTS header as per the HSTS draft specification.

There are some optimisations which minimise the impact on performance. Specifically, the built HSTS header is cached in memory. This leverages the fact that the module is reloaded whenever the configuration is modified.

What changes does the installer make? Or, how to manual install.

The HSTS-IIS-Module.dll is registered in the GAC.

The HSTS_schema.xml configuration schema is copied to the inetsvr\config\schema directory.

The module is registered in IIS. In inetsvr\config\applicationHost.config:
The configuration section is registered - in /configuration/configSections the sectionGroup named "system.webServer":

<section name="hsts" overrideModeDefault="Allow"/>

The DLL is registered - in /configuration/location/system.webServer/modules:

<add name="hsts" type="HSTS_IIS_Module.HSTS, HSTS-IIS-Module, Version=1.0.2.0, Culture=neutral, PublicKeyToken=eafe09d4eb48c4e0"/>

The management GUI is registered. In inetsvr\config\administration.config:
Register the manager module - in /configuration/location/modules:

<add name="hsts"/>

Register the manager module provider dll - in /configuration/moduleProviders:

<add name="hsts" type="HSTS_IIS_Module.Manager.ConfigModuleProvider, HSTS-IIS-Module, Version=1.0.2.0, Culture=neutral, PublicKeyToken=eafe09d4eb48c4e0, processorArchitecture=MSIL"/>

Frequently Asked Questions:

Why build this module?
Whilst it is simple to add a custom header to an IIS site, there is no simple way to add the HSTS header in a way that is compliant with the draft specification (RFC 6797). Specifically from section 7.2:

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

An additional driver for such a module is the seriousness of attack vectors such as sslstrip. It is hoped that simplicity of installation and configuration will avoid any excuse for not implementing the most effective defence against such attacks.

Why not just use an IIS custom header?
Short answer, you pretty much can and, in fact, this is often the answer on forums and wikis all over the Internet.

However, strictly speaking, this solution does not follow the HSTS draft specification as the header will also be injected into non-secure responses. In reality, browsers ignore this header when sent over insecure channels, but this cannot be guaranteed. If a browser mistakenly accepts the header over an insecure channel, it's effectiveness is undermined. This is probably unlikely, but what is the point of a spec if it isn't followed.

Additionaly, as explained in "Why build this module?", I wanted to make configuring HSTS as simple as possible to encourage it's adoption.

Given this module is installed at the server level, will it impact the performance of sites not using HSTS?
No. When the module is initialised an event handler is only attached to every site request on sites that have HSTS enabled in the configuration.

I have a criticism, an idea, an issue, a request, want to say hello.
Please feel free to contact me:
*Email: hstsiis <a in a circle> shaneargo.net
*Twitter: @shane_argo

You should also be able to log issues in the tracker here on CodePlex.

I am running this module in production/test/x86/x64/Server 2K8/Server 2k12/giraffe/anything.
That's not a question. But please tell me. I'd love to hear about it, especially if you are running it on a giraffe.