Is current request being made over SSL with Azure deployment

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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 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:

Azure App Service Application Request Routing

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

Method 2

Not sure whether this will be helpful for you.

2 option.

First option:
ASP.NET MVC RequireHttps Attribute that can be used to decorate a controller or a specific action. this is by far the simplest way to force an HTTPS redirect.

[RequireHttps]
public ActionResult Secure()
{
    return View();
}

Second Option
URL Rewrite
<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
<system.webServer> 
<rewrite> 
  <rules> 
    <rule name="Enforce SSL" enabled="false" stopProcessing="true">
      <match url="/?(secure.*)" ignoreCase="true" /> 
      <conditions> 
        <add input="{HTTPS}" pattern="off" /> 
      </conditions> 
      <action type="Redirect" url="https://{SERVER_NAME}/{R:1}" /> 
    </rule> 
  </rules> 
</rewrite> 
</system.webServer> 
</configuration>

Above are the options for you 100% confirmation to ensure the request is HTTPS


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x