Introduction

This article discusses HTTP to HTTPS redirection as implemented by Google Cloud Run. Today, all websites should deliver traffic over HTTPS. Google Cloud has adopted this policy providing HTTPS for Cloud Run service URLs with automatic redirects from HTTP to HTTPS. However, this redirection is not performed by Cloud Run and we will discuss this redirection in this article.

If you create a custom domain for your Cloud Run service URL, then implementing HTTP to HTTPS redirection is your responsibility. I will discuss this further in Part 2 of this article series.

Let’s Encrypt provides free SSL certificates. Let’s Encrypt minimizes the barriers to adopting HTTPS. Google uses Let’s Encrypt as its public SSL provider for Google Cloud services. Note, this is what I observe and I am not stating any form of Google policy. For Cloud Run, you do not have an option to use your own SSL certificate. Cloud Run is in beta so some of my comments and technical details might change with the production release.

What is HTTP to HTTPS Redirect?

HTTP to HTTPS redirect is a set of methods to redirect a user from an insecure endpoint to a secure equivalent. For example, the URL http://www.example.com is using HTTP as the protocol. HTTP is not secure and does not use encryption. The secure equivalent is usually https://www.example.com.

There are several methods to redirect a client from HTTP to HTTPS:

  • HSTS. HTTP Strict Transport Security. This is implemented in the browser and forces clients to use HTTPS for supported domains.
  • Server side redirect. The server redirects the client using an HTTP status code, e.g. 301, 303, and 307.
  • Client side redirect. The client executes JavaScript code to detect HTTP and reload the page using HTTPS.

HSTS on the surface is the most secure. However, this requires that the client is using a browser that supports HSTS. Hackers often use their own software which can ignore HSTS.

Server side redirect also seems secure. However, there is a small period of vulnerability if the client first accesses a site using HTTP. A man in the middle can intercept HTTP traffic.

Client side redirect is the most insecure. This requires that the client execute JavaScript code, which can be disabled in a browser or modified in flight by a man in the middle.

The most secure method is to not serve traffic at all on HTTP endpoints. However, until browsers default to HTTPS when you enter a URL in the title bar, HTTP will need to be supported. Until then, implement server side redirects. If your entire domain is served over HTTPS consider HSTS with server side redirects. HSTS has a technical issue with requiring the entire domain and subdomains to support HTTPS.

How does Cloud Run implement HTTP to HTTPS Redirect?

Cloud Run service URLs implement HSTS. Cloud Run does not use server side redirects unless the software/services in your container implements them. Specifically, Google implements HSTS on the domain run.app.

Let’s examine a Cloud Run service URL. From my previous article on Cloud Run (link), I implemented a simple Python and Flask hello world application. The service URL is https://sample-flask-example-x5yqob7qaq-uc.a.run.app/

Note: I have left this Cloud Run service running in the cloud. You can test with this endpoint for a while from the time of this article.

Notice the root domain name: run.app. Until today, I did not notice the domain name “app”. We will discuss this in more detail later in this article.

Open a command prompt. We will use the program curl to examine this endpoint. Notice I have changed the endpoint from HTTPS to HTTP for this test.

This command returns the following content:

Notice that Cloud Run happily serves content on the HTTP endpoint. No server side redirection is occurring.

Now open a Chrome browser window. Enter the HTTP endpoint or click here: http://sample-flask-example-x5yqob7qaq-uc.a.run.app/. Notice that Chrome automatically redirects to https://sample-flask-example-x5yqob7qaq-uc.a.run.app/.

Now press F12 to open the Chrome browser. Go to the debugger Network tab. Enter the HTTP endpoint URL again. Notice in the status column a 307. However, the service did not send a 307. Move the mouse over the 307. Now notice “307 Internal Redirect”.

This means that Google Chrome is doing something on our behalf. Chrome is internally simulating a 307, which means Temporary Redirect. In comparison, a 301 means Moved Permanently.

Why and how is Chrome doing this?

This is an example of HSTS (HTTP Strict Transport Security). HSTS is supported by Google Chrome, Firefox, Safari, Opera, Edge, and IE.

Open a new Chrome browser tab. In the address bar enter “chrome://net-internals/#hsts”. Your browser should now look like this:

 

 

In the section “Query HSTS/PKP domain” enter “run.app”.

 

The domain “run.app” has an entry in Chrome for HSTS. The key entries are static_upgrade_mode: FORCE_HTTPS and static_sts_include_subdomains: true. This means that Chrome will always convert your URL from HTTP to HTTPS without the client needing to do anything. The domain run.app is on a list called “Preloaded HSTS sites”. You can read more about this here.

The entry static_sts_include_subdomains: true means that run.app and all subdomains will be redirected to HTTPS by the browser. The can cause problems if you do not implement HTTPS on all subdomains.

Summary

I have only scratched the surface of my deep dive into Cloud Run security. In this article, I looked into how redirection is handled by Cloud Run service URLs. In my next article in this series, I will look into server side redirection and HTTP headers related to HTTPS.

Credits

I write free articles about technology. Recently, I learned about Pexels.com which provides free images. The image in this article is courtesy of Valeria Boltneva at Pexels.

Date created: May 13, 2019
Last updated: May 15, 2019

Related Posts