Enable HSTS protection for CDN assets.

[ScottHelme]

Enabling HTTP Strict Transport Security will afford better protection to CDN traffic.

Currently assets can be served over HTTP or HTTPS from the CDN, there is no redirection from HTTP to HTTPS. By enabling HSTS, capable clients will automatically upgrade to using HTTPS whilst those that are not capable, or may not be capable, will remain on HTTP.

This can be done in the following ways:

1. Inject the Strict-Transport-Security header when serving assets.
2. HSTS preload the CDN domain.
3. A combination of 1 and 2.

[jdorfman]

For reference: https://twitter.com/Scott_Helme/status/761537848218644480

[XhmikosR]

Do other CDNs do this? Google doesn't do this as far as I can tell.

I'm all for security and stuff but the redirect takes some time, even if it's a trivial amount. Also, if the user chose to go with plain HTTP, they know what they get.

[ScottHelme]

Both Google and Microsoft do this: https://scotthel.me/cdn

With HSTS there is no redirection, this is one of the benefits. The browser will use HTTPS on the first request, even if the src attribute specifies HTTP.

It's not the user that chooses HTTP/HTTPS, it's the site owner. If the browser is HSTS compliant then it will use HTTPS, if not it will continue to use HTTP as before.

[XhmikosR]

You are right about the redirection part, of course, I totally mixed those up.

By user I meant the site owner, not the visitor. So if the site owner believes they don't need SSL, who are we to force them? :P

Joking aside, this should be investigated before any actual changes made to the CDN.

I'm personally all for security (I follow your posts for some time now). It's just that better be safe than sorry.

[ScottHelme]

I agree completely, the impact of the change needs to be fully explored, of course.

As for the site owner, whilst they do choose what protocol they embed in the src attribute, they have no control over the user agent. If the user agent is HSTS capable and chooses to upgrade their connection to the CDN, I don't think the site owner has a say there. If they wish to control that, they should host the asset themselves ;-)

[jdorfman]

For the record, starting on day 1 (July 25 2012) we promoted schemeless url's:

We switched to promoting https only on March 31st 2015.

Unfortunately MaxCDN doesn't have a report showing HTTP vs HTTPs (yet) so we have to stick to assumptions.

Joking aside, this should be investigated before any actual changes made to the CDN.

@XhmikosR is dead on. And I am glad you agree, @ScottHelme. With that said I would like to assemble a Task Force (always wanted to say that) that will explore this and put together a plan. TF (so far):

• @jonathanKingston
• @ScottHelme
• @XhmikosR
• @jmervine

A Google Doc might in order. Thoughts?

[jonathanKingston]

Would there be issues if assets got redirected to https?

[XhmikosR]

Well a redirect is definitely slower. With HSTS preload, the browser will use the HTTPS version. See #750 (comment)

[jonathanKingston]

I just meant additionally as well as the HSTS header. If HTTP only needed to be deprecated in the future.

It could be used as a stick for future revisions if the stats back up the change. (It probably calls for another header like the call 0800-jdorfman one "X-Security-redirect: 'Sorry for the speed hump we are saving the web'")

[ScottHelme]

For now I think HSTS will absorb a lot of any remaining HTTP requests. The preload approach is especially favourable here if the redirect is a concern.

It's also worth noting that if a browser got a single HTTP -> HTTPS redirect and then picked up HSTS on one site, it'd never see it again on any other site using the CDN.

Should the CDN ever start redirecting HTTP -> HTTPS, the only browsers that would ever see a continued impact from the redirect would be those that aren't HSTS compliant. Even then, I believe they'd cache a 301 for 30 days, further reducing the impact. However, we aren't there yet, so no real worry.

[jimaek]

It's been a few years since 2016 :) Since then we had a good experience enabling HSTS on the CDN domain on jsDelivr without any problems. So I took the liberty to enable it here as well.

[XhmikosR]

Hmm, we might need to update https://github.com/MaxCDN/bootstrapcdn/blob/develop/test/functional_test.js, I'll try to have a look in the next days.

[L1ghtn1ng]

Expected headers will need to be updated