Redirect straight from http://gov.uk to https://www.gov.uk

[richardTowers]

At the moment, requests to http://gov.uk are redirected to https://gov.uk and
then to https://www.gov.uk.

Why is it like this?

This was done deliberately because we wanted to get gov.uk in the HSTS
preload list (which is a list of domains which browsers should always use HTTPS
for).

The Strict-Transport-Security header is ignored for plain http:// requests, so
we needed to redirect to https://gov.uk to be able to serve the response in a
way which would be respected by browsers.

In the time since we added this redirect, gov.uk has been put on the HSTS preload list:

https://github.com/chromium/chromium/blob/master/net/http/transport_security_state_static.json

{ "name": "gov.uk", "policy": "custom", "mode": "force-https", "include_subdomains": false },

Why should we change it now?

There's a theoritical web performance cost to the extra redirect. An extra TCP
connection to gov.uk:443, and an extra TLS handshake for https://gov.uk, and an
extra HTTP request. All of which we could have skipped if http://gov.uk redirected
straight to https://www.gov.uk.

This is mostly theoretical because gov.uk is on the HSTS preload list, so
browsers won't make the first request (to http://gov.uk).

This commit only changes the behaviour for the http:// redirect (the 801
virtual status code), so nothing will change for HSTS respecting user agents
which never make http:// requests.

User agents which don't follow HSTS (e.g. curl) will get a simpler redirect,
which will be a little bit faster.

Is there some risk of disaster here?

We have to be very careful with gov.uk's HSTS status. There are lots of
subdomain of gov.uk which still don't support https (including most of the
domains we "transitioned"). Accidentally putting gov.uk on the HSTS preload
list with includeSubdomains set would effectievly break all the http:// subdomains.

This happened by accident in a version of IE in 2019 (due to a mistake on microsoft's side).

This change should not increase the risk of that kind of issue - https://gov.uk
will still serve the Strict-Transport-Security header, as it has since 2017.

[richardTowers]

See also https://bugs.chromium.org/p/chromium/issues/detail?id=700280#c9 which was the ticket that got gov.uk added to the HSTS preload list in Chrome.

[ChrisBAshton]

Interesting read! 👍 Change looks good.

[karlbaker02]

Looks good 💯 I wasn't expecting req.http.host to be the host and domain, as I wasn't expecting req.url to be the path, so I have learnt something too 🙂

[ChrisBAshton]

The Slack Seal has brought this back under scrutiny 😁

@richardTowers is there any reason why this wasn't merged? Is it something you'd like Platform Reliability to carefully roll out next sprint?

[richardTowers]

🦭

I think this is so low value that (even though it's low risk) it's probably not worth doing. I've converted it to a draft to quieten the seal.

Also coming back to it with a fresh set of eyes, I wonder if this wouldn't cause problems in non-production environments (staging and integration) since I hardcoded www.gov.uk 🤔