Since October 2016, when we launched the new site, FT.com has only been available over
Over the past few months we’ve implemented the HTTP Strict Transport Security (HSTS) specification on FT.com, to ensure that our users will only ever talk to us over a secure connection.
This is the story of how we got there, and the hurdles we hit.
What is HSTS?
HSTS is a declaration websites can make using HTTP response headers, that tells browsers to only use secure connections when talking to the site.
This is mostly defined in the IETF RFC 6797, but there is one additional directive we use that’s not included,
What is preloading?
We include the
preload directive to protect users that make an initial insecure request to FT.com.
It states that we are happy for FT.com to be included in a list of secure sites distributed in all major browsers.
This means that even an initial insecure request will be upgraded to a secure connection automatically by the browser.
For more information on preloading, check out the HSTS Preload List Submission site maintained by the Chromium project.
For insecure requests to FT.com, there is only ever a redirect response.
$ curl -I -X GET http://ft.comHTTP/1.1 301 Moved Permanently
Location: https://ft.com$ curl -I -X GET http://www.ft.comHTTP/1.1 301 Moved Permanently
But why does
http://ft.com redirect to
https://ft.com, would it not be one less redirect to send users straight to
The reason is that you want users to have HSTS policies set for both hosts, which would not be the case if users never visited
We actually supply two different
Strict-Transport-Security headers, depending on the host.
$ curl -I -X GET https://ft.comHTTP/1.1 200 OK
Strict-Transport-Security: max-age=63072000; preload$ curl -I -X GET https://www.ft.comHTTP/1.1 200 OK
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Pulling apart the headers, there are a few directives we define.
max-age states how long a user agent should respect the policy. Each new response including this header will reset this time back to the
includeSubDomains means this host, and all subdomains of this host should be covered by the HSTS policy.
preload directive is as we described earlier.
The difference is that we don’t include
includeSubDomains for requests to
https://ft.com. This is very intentional.
There are a number of legacy systems at the FT using subdomains that don’t support secure connections. There are also a number of other subdomains that are secure, but the teams running them may not be prepared for HSTS.
This combination of headers and directives means that we limit this policy to only
www.ft.com and all its subdomains (i.e.
*.www.ft.com), while still allowing insecure connections to several
We started launching the new site long before October 2016, but have only started to declare HSTS support since January 2018. Legacy systems running on
www.ft.com were the main hurdles we had to work with.
Biggest of them all was the old site, in launching we gradually rolled out the the current FT.com to a percentage of users until we hit 100% in October 2016. Until then we needed to support insecure connections for the previous FT.com.
We also had a number of systems running off
www.ft.com under various paths that didn’t support secure connections. One such example was the previous live blogs system, which was updated to work over secure connections.
For your typical site, you cannot get onto the preload list unless all requirements are met. However, we don’t actually conform. After sending a kind email to the HSTS project asking for an exception to be made for FT.com, we can now protect our users while working on the long tail of subdomains.
includeSubDomains directive on requests to
https://ft.com is the ultimate goal.
Longer term, rolling out HSTS to the many hundreds of domains that belong to FT Group will not be trivial.
Making it the default for new domains, however, is a no-brainer.