Redirect to HTTPS while using a load balancer - very common web hosting scenario for MVC applications

[spacecat]

The RequireHttpsAttribute class is missing some common web hosting scenarios such as when a web server is behind a load balancer. If this is the case using the RequireHttpsAttribute will result in a redirect loop. There are some folks that have come across this problem and solved it but I believe a solution should be included in the RequireHttpsAttribute class. If not in the RequireHttpsAttribute class itself, in some samples/documentation where people can copy-paste a best-practice snippet.

One of the better sources solving this problem I believe is this one:
https://gist.github.com/runesoerensen/915869

But if you google for the term "filterContext.HttpContext.Request.Headers["X-Forwarded-Proto"]" you will also find other similar solutions extending the RequireHttpsAttribute class.

[danroth27]

@blowdart

[blowdart]

You can see from the linked example is that it only works for one specific load balancer. There's then links to one that one works on app harbour and so on. There's no real "standard" for this (although usually it's X-Forwarded-For, so rather than hard coding a header and the expected value that needs to be configurable.

Note that this encourages bad security behind the load balancer, where traffic flowing from the load balancer to the server isn't protected by HTTPS. This isn't something we should encourage

My opinion is to not support this out of the box.

[spacecat]

I totally agree that Web hosting companies should use https all the way. I was surprised that this was not the default. I know of only two companies doing this. App harbour and Swedish city network. App harbour through their own documentation and city network through own experience running a mvc 5 app in their shared hosting environment. Due to this problem I was forced to move to Azure which doesn't have this problem. So the question remains. How to better communicate this to Web hosting companies because my gut feeling tells me the majority terminate https at load balancer and how to teach them to use the method Azure is using which perhaps is the best practice way of handling https with a load balancer . Because I don't believe the answer is to tell people to buy a vps, dedicated server or move their app to Azure for more cost effective scenarios or smaller web apps.

[runesoerensen]

Stumbled upon this thread and I think there may have been some misunderstandings here; This is an old issue, but I wanted to clarify how and why there is a legitimate use case for supporting this header.

AppHarbor does indeed terminate TLS at the load balancer level and use the X-Forwarded-Proto header to indicate the protocol of the client connection. Similarly, the X-Forwarded-For header is used to indicate the client IP(s). It's however worth noting that we do not terminate TLS connections to then let unencrypted traffic flow over any public networks - that would be insecure and I certainly agree that such a setup should not be encouraged.

Instead, TLS is terminated by the load balancer and then proxied to backend servers on a private network. That makes a big difference and is a secure and very common architecture. Neither the naming of this defacto standard header, nor the use case, is specific to a single host, webserver or configuration. The very same approach is implemented by other hosting providers such as AWS, Heroku and Azure.

For other folks who may find this discussion while searching for a solution: ASP.NET Core now supports these headers! Apps can be configured to use the various X-Forwarded-* headers by using ForwardedHeadersMiddleware. Here's a sample showing how to use it and a related discussion on this topic.

[bloritsch]

Please note that Amazon Web Services also uses this approach in ElasticBeanstalk hosted applications. This is not a problem that is going to go away any time soon. Fixing the problem by terminating the SSL at the IIS instance is very difficult to do in the cloud hosted environment. Terminating at the loadbalancer provides a predictable and quick deployment option.