Is current request being made over SSL with Azure deployment

Question

context.Request.IsSecureConnection

Always returns false in an Azure deployment even when the connection is being served over HTTPS. After looking through the headers sent for an Azure deployed site I've found:

X-Forwarded-Proto=https

Does this header guarantee that the client connection to the website is under HTTPS in the same way that context.Request.IsSecureConnection does?

Answer 1

IMPORTANT NOTE:

The custom check referred to in my answer is no longer required for ASP.NET on .NET Framework 4.7 and ASP.NET Core 2.0.

Both HttpContext.Request.IsHttps (Core) and HttpContext.Request.IsSecureConnection will return True if the request originated over HTTPS in Azure App Service.

That's what i tested with, it may have happened sooner in the life of those stacks (e.g. .NET Framework 4.6.x). You should be fine in any case since App Service now runs your application on top of .NET Framework 4.7.

You most probably have to make the check for any other programming stack.

---

I'm not asking how to force HTTPS, I'm asking why in Azure deployment is context.Request.IsSecureConnection returning false even when the request is over HTTPS.

Here's why:

The Azure App Service frontend layer TERMINATES the TLS channel (aka TLS offloading) and opens a new plain HTTP connection to your Web Worker, where your code lives. Routing is performed by ARR (Application Request Routing).

Source:
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AZR305
(View slides, Slide 12)

Therefore, from the point of view of your code every single request is "insecure".

X-Forwarded-Proto=https hints about the original request (that hit the frontends).

If checks have to be made, make them against X-ARR-SSL instead.

ARR is attaching a special request header to every request that arrives over HTTPS. The value contained in X-ARR-SSL provides information about the TLS server certificate that was used to secure the TCP connection between the client (i.e. browser) and the ARR frontend.

e.g.:

X-ARR-SSL: 2048|256|C=US, S=Washington, L=Redmond, O=Microsoft Corporation,
           OU=Microsoft IT, CN=Microsoft IT SSL SHA2|CN=*.azurewebsites.net

A whole more info around that here:
https://tomasz.janczuk.org/2013/12/secure-by-default-with-ssl-in-windows.html

Tomasz is the author of the iisnode project, which is the mechanism for running Node applications on IIS in Azure App Service.

EXECUTIVE SUMMARY

App Service uses Application Request Routing, which is also the point where TLS is terminated. Since the traffic that hits your web worker will then be plain HTTP, you need to check this header to tell if the request originated over TLS:

if (request.headers['x-arr-ssl'])
{
    // We're good
}
else
{
    // Request made over plain HTTP
}

If you're running on .NET Framework 4.7 or .NET Core 2.0, you do not need to make this check, there's baked in logic to return the correct value for HttpContext.Request.IsSecureConnection and HttpContext.Request.IsHttps (.NET Core).