51–60 of 78 posts
If you start seeing unexplained errors on pay-as-you-go phones, you'll know why; although if this facility gains popularity then I'm sure they'll be pressured to stop modifying content.
Careful! I've seen proxies (TracFone I think) subtly modify JSON files by removing whitespace, probably in the name of download speed. That will break the hashing. If you start seeing unexplained errors on pay-as-you-go phones, you'll know why; although if this facility gains popularity then I'm sure they'll be pressured to stop modifying content.
Earlier quoted context omitted.
The point is that with a signature you wouldn't have to change all the pages including the resource, but just sign the updated resource with the same key.
It's just a semantic question. Does a URL point to a specific version of a resource or does it point to whatever the server considers to be the resource at a given time. It would seem more desirable to be able to point to a specific version, instead of allowing a third party to be able to insert implicitly trusted code without acknowledgement.
If that's not convincing, consider the case where it's my own JS. I don't trust myself to run a CDN; I don't trust a CDN with the ability to modify my code. This allows me to build a single-page app that has ridiculously long cache lifetimes (so my own server load is low), and hand the actual, changing code off to a CDN, but verify my own signature on the data.
If that's not convincing, consider that data signing keys can generally be kept on non-internet-facing machines (and you can airgap, use a HSM, whatever), but performant SSL implementations by definition have to have their private key be in memory on an internet-facing server.
What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.) To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for…
> What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. Only if your page requires JavaScript to function and doesn't gracefully degrade. None of us would ever write that sort of page, would we?
Earlier quoted context omitted.
It leaks private user info -- a malicious server could include a JS file confirmed to be highly sensitive/top secret, and measure whether the client already has that cached. If so then the user is confirmed a sensitive target.
you could just add a new public=true option to counter this. I think you can even already check that with an iframe (or js head inject & timing) anyway, no need for CSP for that.
<script src="..." is very dangerous. At best, you can vet the src and check to see if it's benign or not. Often times, that vendor and their "1-line of javascript to get our whiz-bang service" in turn loads other javascript files. I don't see how cryptographically signing the bootloader solves anything in this case. Compromised analytics or vendor javascript will still lead to total site pwnage if I'm reading this ri…
It also lets you use CloudFront as a CDN for your own JS without having to trust them to serve the content as you described it, if you calculate your hashes based on the scripts you sent them.
Earlier quoted context omitted.
How is that dangerous?
It leaks private user info -- a malicious server could include a JS file confirmed to be highly sensitive/top secret, and measure whether the client already has that cached. If so then the user is confirmed a sensitive target.
You're just trading one problem (someone learning I previously requested a file) for another (leaking referrers to a CDN).
Also, if you're loading "highly sensitive/top secret" data with a or tag, you have bigger problems.
Earlier quoted context omitted.
D'oh; that makes sense. Maybe I should refrain from posting my gut reactions (or at least wait until I'm awake first). =)
No, it was a very good point. Not everyone adds hashes to filenames, and to me it seems that you're right in that weird caching can break pages that way. If indeed this is the case, subresource integrity needs a big warning sign about that. For me, your comment was that warning sign, so please keep posting while you're not awake yet.