Enable HSTS to tell browsers to prefer HTTPS for code.jquery.com

[Krinkle]

This would solve:

• https://github.com/jquery/codeorigin.jquery.com/issues/55
• https://github.com/jquery/demos.jquerymobile.com/pull/19

Sub steps:

• [ ] Set Strict-Transport-Security: max-age=106384710; includeSubDomains; preload in our Nginx backend configuration as a header on our main content domains. Taking care to apply this both to responses generated via WordPress for pages on api.jquery.com and code.jquery.com, as well as static files served from codeorigin.jquery.com.
• [ ] Submit jquery.com to https://hstspreload.org/

[mgol]

For jquery-wp-content development we use Vagrant hosts at vagrant.real-domain, e.g. http://vagrant.api.jquery.com. So while it'd be good to have HSTS enabled for all jQuery domain, we need a plan for handling these Vagrant subdomains.

[mgol]

From my comment at https://github.com/jquery/codeorigin.jquery.com/issues/19#issuecomment-792371444: a redirect to HTTPS is one of prerequisites of adding a domain to the HSTS preload list as documented at https://hstspreload.org/. Judging by @Krinkle's comment at https://github.com/jquery/codeorigin.jquery.com/issues/19#issuecomment-792362555 it looks like we can enable HSTS but it will never be preloaded.

[Krinkle]

@Krinkle a redirect to HTTPS is one of prerequisites of adding a domain to the HSTS preload list as documented at https://hstspreload.org/. So it looks like we can enable HSTS but it will never be preloaded?

I'm not entirely sure yet. It might be. I think it might be possible so long as the apex domain (jquery.com) has a redirect, and/or so long as it redirects when the Upgrade-Insecure-Requests header is set on the incoming request; both of which we can safely do.

[mozfreddyb]

@mikewest Do you think you could figure out if there's a way to get the jquery code domains on Chromium's HSTS preload list by relaxing the "HTTP to HTTPS redirect" requirements, that are usually applied? This could be really useful and site-owners seem to be eager. I'd be happy to investigate the Firefox side of things.

[mikewest]

The person I would have asked in Chrome isn't available; so, let me throw @devonobrien and @sleevi under the bus to see if they know who to talk to about exceptions to our HSTS policy.

[mgol]

Is the rule we're talking about now mostly making sure that the site is committed to HTTPS so that supporting HSTS, in theory, doesn't introduce a change in behavior but only makes it safer? Otherwise, this shouldn't interfere. Maybe we could, indeed, get an exception here. The jQuery CDN is used a lot so having HSTS enabled would improve overall Web security even if we don't enable a "regular" redirect to HTTPS.

[mozfreddyb]

Just noticed that Firefox code is technically able to force an inclusion regardless of current HTTPS status using a specific flag, e.g., if the Chromium list entry uses a specific policy value. Should be possible to use that very same mechanism (or a similar one). I'll start the conversation on our side, once this is progressing with on the other ends :)

[devonobrien]

@mikewest Yep, that's me; I now own our HSTS Policy and handle exception requests.

Currently, code.jquery.com doesn't meet a handful of preloading requirements, but we do have an exception for high-value domains [1], which provide an outsized security benefit to clients per entry compared to the vast majority of subdomains. This domain pretty clearly falls into this category, and we can add it to the preload list manually.

While it's clear that there are problems asserting includeSubDomains for jquery.com, could we still safely assert for code.jquery.com if we preloaded it directly? Also, to avoid the lengthy and painful process of removal from the preload list in the event of a problem, we strongly advise following a conservative deployment strategy for HSTS [2] before preloading to ensure that there will be no issues. Removals from the HSTS preload list can take up to 3 months to reach most clients.

[1] https://github.com/chromium/hstspreload.org/wiki/Preload-List-Processes#requirements-for-manual-hsts-entries [2] https://hstspreload.org/?domain=code.jquery.com#deployment-recommendations

[Krinkle]

@devonobrien If we redirect port/80 only if Upgrade-Insecure-Requests is set, would that get approved through the "regular" process?

From a quick scan through the chromium/hstspreload.org repo I could not find indication that the main test used today passes this, is that correct? Would that make sense to do? Or is it preferred to have an unconditional redirect? (Some the reasons for this are outlined at https://jcs.org/2021/01/06/plaintext, and issue https://github.com/chromium/hstspreload.org/issues/177 seems to have requested this in the past.)

If not through the regular process (yet), would it suffice for a manual/exemption request that we serve HSTS with includeSubDomains on jquery.com and code.jquery.com, but redirect code.jquery.com http/80 only when Upgrade-Insecure-Requests is set?

Or perhaps simpler, could we serve HSTS with includeSubDomains as-is today from jquery.com and code.jquery.com and leave it at that? This apex domain we're fine redirecting to HTTPS unconditionally (and already does), and it seems there isn't currently a redirect test for specific subdomains in place today.

[devonobrien]

@Krinkle The "regular" process would still fail because code.jquery.com is a subdomain of your registrable domain; however due to the relatively high value of code.jquery.com, we're able and willing to make an exception to preload that subdomain directly. In general, the arguments against unconditional upgrades seem somewhat unpersuasive, but given the impact that preloading code.jquery.com will have for the security of the web, we are supportive of exempting this requirement as well.

In order of decreasing preference, here are the options we can pursue:

1. Manually preload jquery.com with includeSubDomains. If clients that consume the HSTS preload list need to connect to e.g. the vagrant subdomain mentioned above, they will not be able to connect unless these domains provide a HTTPS endpoint.
2. Manually preload code.jquery.com with or without includeSubDomains
3. Serve HSTS header from the domain(s), but do not preload.

As far as redirects go, we will be bypassing the hstspreload.org submission form, so we don't need to over-index on the general-purpose warnings that site throws for these domains (e.g. it makes no distinction on whether Upgrade-Insecure-Requests is set).

[Krinkle]

I don't think we should enforce HTTPS on code.jquery.com. Leaving it accessible over HTTP appears the right move for longevity and wider range of access. We advertise both HTTPS and SRI by default in snippets, and also link to HTTPS from all demos and download links.