HTTP Strict Transport Security for FT.com
Our road to enabling HSTS, inspired by the Yelp story.
Since October 2016, when we launched the new site, FT.com has only been available over https://.
However, we still have many insecure links pointing to our site, leaving users at risk from session hijacking and protocol downgrade attacks.
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, preload.
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.
Our setup
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
Retry-After: 0
Location: https://ft.com$ curl -I -X GET http://www.ft.comHTTP/1.1 301 Moved Permanently
Retry-After: 0
Location: https://www.ft.com
But why does http://ft.com redirect to https://ft.com, would it not be one less redirect to send users straight to https://www.ft.com?
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 https://ft.com.
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 max-age value.
includeSubDomains means this host, and all subdomains of this host should be covered by the HSTS policy.
Finally the 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 ft.com and www.ft.com and all its subdomains (i.e. *.www.ft.com), while still allowing insecure connections to several *.ft.com subdomains.
The hurdles
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.
What’s next?
Serving the includeSubDomains directive on requests to https://ft.com is the ultimate goal.
Our user facing sub-sites like myaccount.ft.com and markets.ft.com will be our next focus to start protecting.
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.
