Archive for February, 2014

SSL Termination and ASP.NET

Wednesday, February 12th, 2014

This seems to hit everyone as they start out using SSL Termination and ASP.NET..

When you have a website running on a server with an SSL certificate installed, HttpRequestBase has a public property you can access as Request.IsSecureConnection that happily tells you if you’re running over SSL or not. This is useful when you need to generate full canonical URIs (for outbound links or return URIs) that include the scheme.

As your business matures and you scale out, maintaining SSL certificates across your IIS cluster becomes a headache, and many people opt to use SSL Termination – installing the SSL certificate only on a load balancer or reverse proxy. The reverse proxy then deals with the SSL encryption and decryption of traffic, forwarding the traffic, unencrypted, to the origin webserver.

So you take your code, that was generating URIs, and move to an SSL terminated environment and your code breaks. The URIs all get generated wrong, and you’re not sure what’s going on. You crack open the codebase on your local dev machine, with your self signed debug certificate and run a few tests – everything works. This is because on your local dev environment, you’re not SSL terminated, and on your staging and production environments, you are – you’re not going crazy, there isn’t any SSL here.

And you still need to generate valid URIs.

Supporting this scenario

There’s a non-standardised convention based header that a lot of terminating load balancers add to the HTTP headers of your request when they encrypt and decrypt your traffic – “X-Forwarded-Proto” which will be set to “https” if your load balancer has modified the scheme of your traffic. Hopefully your load balancer will add it, or support you adding it as a rule or configuration setting.

Request.IsSecureConnection is false in this scenario, and should always be false.- after all, the connection between your server and your load balancer is insecure, and Microsoft should resist the urge to change the meaning of this flag, so you’re going to want to support it another way.

So do the simplest thing that should possibly work, here are some extension methods:

using System;
using System.Linq;
using System.Web;

public static class SslTerminationExtensions
    public static bool IsSecureOrTerminatedSecureConnection(this HttpRequestBase request)
        if (!request.IsSslTerminated())
            return request.IsSecureConnection;

        var header = request.Headers["X-Forwarded-Proto"];
        return string.Equals(header, "https", StringComparison.OrdinalIgnoreCase);

    public static bool IsSslTerminated(this HttpRequestBase request)
        return request.Headers.AllKeys.Contains("X-Forwarded-Proto");

This will allow you to change any calls to Request.IsSecureConnection for calls to Request.IsSecureOrTerminatedSecureConnection() and your code will work correctly in both your self-signed dev environment, and your SSL terminated dev and QA environments.

The Assassination of OR/Ms …by that coward, relational storage

Tuesday, February 11th, 2014

Here’s a talk I’ve recently given on OR/M’s, what they’re good at, the backlash some people feel towards them, and where they’re awesome.

If you’d like me to talk about this, or any of the topics posted here, get in touch.