Add Subresource Integrity for JS and CSS files

[morloy]

After moving our Meteor assets out to a CDN, the Mozilla Observatory kept complaining about missing Subresouce Integrity in our JavaScript files.
This PR adds a sha512 hash to all basic Meteor files served to the client.

Solves meteor/meteor-feature-requests#35.

[abernix]

If we were to update tools/isobuild/bundler.js, here to also generate and store a sha512 into the manifest (thus ensuring that item.sha512 is defined above) — what would be the use-case for needing to generate this hash at run-time (on each request), as would be occurring here?

(It seems like this would be the way to go, but I'm curious if I'm missing something.)

[morloy]

As explained below, using SHA-512 for the hash in the manifest and truncating it for filenames would be a good approach in my opinion.

[abernix]

Perhaps using sri would be a more appropriate name here, since the suggested algorithm might update over time? (And has already changed since when we first started discussing this — for example, SHA256 was no longer recommended by the NSA, if I recall)

[abernix]

I had been tempted (both today and in the past) to suggest that we switch to using a newer cipher for hash (which currently uses SHA-1, 40-bytes in length — in hex) and just use that for the SRI — relying on only a single hash! 🙌🤔

That temptation was originally based on me thinking we could go with SHA-256, which has a relatively short hexadecimal representation (64-bytes) and would still work fine as a filename (which hash is frequently used for in builds and when serving files to clients!).

Unfortunately, as hashes become more complex, they become longer and the hex representation of a SHA-512 hash would be 128-bytes — a super long filename. (Maybe too long?)

Most problematically though, SRI requires base64 encoding which, while shorter than 128-bytes for SHA-512, fails to be useful as a filename because of the base64 encoding (/, in particular), so my temptation seems to be well-prevented.

[morloy]

I‘d recommend switching to SHA-512 and simply truncate it for the filenames. This seems to be totally fine. If more information needs to go into the filename, there’s Base58 or UNMISTAKABLE_CHARS, that would give Base55.

Recoding the hash from hex to Base64 for SRI would be trivial.

[abernix]

I'm curious if this crossorigin="anonymous" might potentially cause problems for existing deployments which might necessitate the presence of user credentials (as defined here; e.g. HTTP Auth, Cookies, etc.) in order to serve the JS or CSS files (let's say the Meteor's deployment was fully behind that forced HTTP Authentication).

From what I understand, it's mandatory for crossorigin to be set for SRI to work (See 0, 1), but I'm afraid this might need to be toggleable between the valid options, anonymous and use-credentials.

Any thoughts?

[morloy]

Having this configurable sounds good to me. But where would this config go ideally? Any ideas?

[abernix]

Same question as above!

[morloy]

@abernix I added WebAppInternals.enableSubresourceIntegrity(use_credentials = false) to make the whole SRI optional and allow to select either anonymous or use-credentials for the crossorigin.
By default, SRI is disabled to make sure that we don’t break any existing setups. Hope this fine now.

[abernix]

LGTM!