Secure HTTP Redirection

Unless you’ve been living under a rock, the world’s websites “should” all be served up using encryption with HTTPS – and no longer unencrypted with HTTP.

Yet there are many people who don’t quite understand the reasons why encrypting website traffic for your visitors is so important. But I’m not here to go into that.

What I want to achieve here is some understanding and awareness of the next problems potentially facing site owners – particularly around the correct method for redirecting from HTTP sites to HTTPS sites.

Problem Statement

Web servers configured to listen on Port 80 (HTTP) and Port 443 (HTTPS) at the same time (sending requests to the same logical application) could accidentally respond over Port 80 with sensitive data that is unencrypted via HTTP.

Let me explain how this is possible.

Imagine for a moment your web server isn’t being protected behind a Web Application Firewall (WAF), and that it’s configured to listen and respond on both Ports 80 and 443.

This can happen a couple of different ways. Usually I’ll see an Nginx or Apache configuration that has two enabled sites with a “server” section in each – one with TLS config for Port 443, the other just plain Port 80 – and each one points to the same application or root folder – for example, PHP or something like that.

And that’s the issue. You’re trusting your web application (maybe WordPress or something like that) to perform the necessary business logic to ensure that non-secure HTTP requests are always redirected to their HTTPS counterpart.

If it’s not the application doing the redirecting, the common alternative might be Nginx or Apache redirection rules, oftentimes poorly implemented and sometimes located in bad places like .htaccess files. It’s better – but again relying on this type of configuration (especially when it is managed and ships along with the code for the web application) has it’s own problems.

The ideal HTTP redirection to HTTPS

Suggestion #1 – stop your Nginx/Apache web server from listening on Port 80.

When you think about this carefully, we want to live in a world where web traffic is always encrypted. Your precious web traffic originates from your origin – in this case likely your Nginx/Apache infrastructure. Stop listening on Port 80.

Suggestion #2 – perform only strict HTTP to HTTPS redirections.

When redirecting HTTP traffic to a HTTPS site, I see lots of people trying to be too clever and overthink it. For example, some people get fancy and they’ll want to do stuff like this:

http://example.com/ == redirected-to ==> https://www.example.com/

Notice what happened here? The redirection jumped the visitor from example.com to http://www.example.com – the destination addresses for these sites could be completely different. This is NOT a clean and strict redirection.

To perform a strict redirection NEVER change the host header or any other part of the requested URL, just take the request and make it HTTPS. That’s it.

If the URL is still not correct, you should let the HTTPS server do any successive redirections to eventually (and securely) direct the visitor to the correct location.

Suggestion #3 – let your WAF, Edge, or other daemon do the redirection.

If you’re still hung up on using Nginx/Apache to host all your web things, and you’re not living in the AWS Cloud where all the cool kids hangout, then here’s a few sub-tips to consider.

• Guidance is available from Cloudflare on this (note they also suggest not performing redirections on your origin servers for fear of redirection loops)
• Consider using a separate Nginx process with a very small config (only a few lines of configuration needed for it)
• You can containerise the task of HTTP redirection with numerous options available on Docker Hub and other container repositories.
• If you’re relying on ACME challenges (e.g. Let’s Encrypt cert renewals) over HTTP there are some lightweight solutions like this one on Github.

Summary

In 2022, it is estimated that anywhere from 91% to 98% of web sites (depending on location) are available on HTTPS, which is a great thing.

Just make sure you’re doing the redirecting from HTTP to HTTPS the right way, because if not, you could be creating future situations that result in compromise.

Until next time, stay safe out there.

---

* Big thanks to FLY:D and Unsplash for the featured image on this story.