Serving ZeroClipboard SWF from CDNJS fails when used from HTTPS page and then from HTTP page

[aoles]

I use the approach described in Cross-Protocol Limitations to serve ZeroClipboard.swf from CDNJS on pages for which the protocol can vary. Things worked fine until yesterday, but today I've noticed that it doesn't work for pages served over HTTP any more, but for ones using HTTPS it works fine. I use the following configuration:

ZeroClipboard.config( { swfPath: '//cdnjs.cloudflare.com/ajax/libs/zeroclipboard/2.2.0/ZeroClipboard.swf' } );

I tried to use HTTP explicitly for content served over HTTP, but this also doesn't work now:

ZeroClipboard.config( { swfPath: 'http://cdnjs.cloudflare.com/ajax/libs/zeroclipboard/2.2.0/ZeroClipboard.swf' } );

Thank you for any input!

[tofutim]

yeah something wrong with the cdnjs version

[kangaechigai]

This is almost certainly due to HSTS (which CDNJS enabled relatively recently). If your browser supports HSTS and you access cdnjs over https, it will insist on redirecting any http requests to https for that domain for the next 180 days (based on the strict-transport-security:max-age=15552000; includeSubDomains; preload header cdnjs sends with the response), even if you try to force it. There are ways to reset it locally in some browsers, but the only real solution (if you simply have to support http) is to use a different CDN that doesn't set the Strict-Transport-Security header.

Update/clarification: cdnjs.cloudflare.com does not currently send the Strict-Transport-Security header, so assets hosted directly on http://cdnjs.cloudflare.com (e.g. the main ZeroClipboard.js library) can still load over http, but certain other assets (e.g. ZeroClipboard.swf) redirect to http://ajax.cdnjs.com. https://ajax.cdnjs.com does send the Strict-Transport-Security header, so browsers that supports HSTS will automatically redirect http://ajax.cdnjs.com to https if you've visited https://ajax.cdnjs.com in the past 180 days. Chrome will redirect http://ajax.cdnjs.com to https whether or not you've ever visited https://ajax.cdnjs.com, since cdnjs.com and its subdomains are included in Chrome's HSTS preload list, which is expected to be used by other major browsers soon as well.

[aoles]

Thanks @kangaechigai for clarifying this! I circumvented this issue in my project by using jsDelivr and locally-hosted files.

[ScottHelme]

@kangaechigai The linked tweet says that HSTS was only turned on for the website and API, not the CDN assets which are hosted from the cdnjs.cloudflare.com subdomain. I'm not sure this would have had an effect in this case. Does the src attribute in the script tag load via http or https?

[kangaechigai]

@ScottHelme It's true that the tweet I linked to didn't explicitly state that HSTS was enabled for CDN assets, but it was the closest thing I could find then to indicate an approximate timeline. HSTS is definitely enabled for ajax.cdnjs.com, which is where the actual ZeroClipboard.swf asset is hosted. cdnjs.com (including all subdomains) is also now in Chrome's HSTS preload list.

[ScottHelme]

Most assets on CDNJS are loaded from cdnjs.cloudflare.com aren't they? the CDNJS preload entry doesn't apply to that domain and you can see that the particular subdomain on CloudFlare is not preloaded.

[kangaechigai]

I hadn't actively tested anything but the ZeroClipboard.swf asset, since that was what I was trying to use and what this thread is really about, but I think you're correct for the majority of CDNJS assets. I'll try to go back and update my comments above later to clarify.

It looks like ZeroClipboard.js can load insecurely, but it doesn't actually work on insecure pages, because it depends on ZeroClipboard.swf, which redirects to http://ajax.cdnjs.com/ajax/libs/zeroclipboard/2.2.0/ZeroClipboard.swf and ends up on https, since ajax.cdnjs.com is covered by the cdnjs.com entry in the HSTS preload list:

{ "name": "cdnjs.com", "include_subdomains": true, "mode": "force-https" }

That redirect to ajax.cdnjs.com seems to happen for many other Flash assets as well (e.g. WebSocketMain.swf + video-js.swf + Moxie.swf), so many libraries that actually depend on their Flash components and don't use allowInsecureDomain are likely to have problems when loaded from CDNJS on insecure pages.

[konklone]

This issue is causing some concern around deploying HSTS to cdnjs.cloudflare.com, which hosts ZeroClipboard.

But as @terinjokes noted at cdnjs/cdnjs#4328 (comment) in August 2016:

Can you implement ZeroClipboard leveraging other browser technologies? All modern browsers (the ones that would follow HSTS headers or preload lists) support execCommand('copy'), with the temporary exception of Safari (which is getting support in the next release).

So adding HTML5 support would make a meaningful difference in security enforcement for modern browsers.